[JS] MVC패턴 & Flux패턴

MVC패턴 (Model, View, Controller) : 양방향 데이터 바인딩

Model, View, Controller 의 약자이다

Model에 데이터를 저장하고, Controller를 이용하여 Model의 데이터를 관리(CRUD)합니다
Model의 데이터가 변경되면 View로 전달되어 사용자에게 보여짐

사용자가 View를 통해 데이터를 입력하면, View역시 Model을 업데이트 할 수 있다는 점
즉, 데이터가 양방향으로 흐를 수 있다는 것

 

만약 여기서 규모가 커지면 Model과 View가 많아져

View가 다양한 상호작용을 위해 여러개의 Model을 동시에 업데이트하고 Model역시 여러개의 View에 데이터를 전달하는 상황이 발생한다.
한 Model이 업데이트되면 View가 업데이트되고, 업데이트된 View가 또 다른 Model 을 업데이트하는 식의 복잡한 데이터 흐름을 가지게 된다
이렇게 많은 의존성을 가지면 Model 의 개수가 많아질수록 각 Model에서 발생한 이벤트가 애플리케이션 전체로 퍼져나갈 때 예측하기 힘들어 진다

장점

비교적 간단한 패턴으로 구조파악과 확장에 용이함

단점

뷰와 모델의 완벽한 분리가 어렵고 앱이 커지면 컨트롤러의 코드량이 커져 유지보수 하기가 힘듦

MVC는 금방 복잡해진다고
페이스북에서 말하고 이 해결방안으로 단방향 데이터 흐름을 가지는 Flux패턴을 고안해냈다

 

 

---

Flux패턴 : 단방향 데이터 바인딩

Client-Side웹 어플을 만들기 위해 사용하는 디자인 패턴이다

대규모 애플리케이션에서 단방향으로 데이터 흐름을 일관성 있게 관리함으로써 프로그램의 예측가능성을 높이기 위해 등장

사용자 입력을 기반으로 Action을 만들고, Action을 Dispatcher에 전달하여 Store(Model)의 데이터를 변경한 뒤 View에 반영하는 단방향 흐름으로 애플리케이션을 만드는 아키텍쳐

각 요소들은 단방향 흐름에 따라 순서대로 역할을 수행하고, View에서 새로운 데이터 변경이 생기면 처음부터 다시 이 순서대로 실행한다

이렇게 예외없이 데이터를 처리할 수 있게 됨

장점

• 양방향 흐름으로 인한 혼선을 줄일 수 있고, 모든 상태가 Store에 있어서 변경사항을 여러 컴포넌트에 전달하기 쉽다
• 데이터 변화에 따른 성능저하 없이 DOM객체 갱신이 가능
• 단방향 데이터 흐름이기에 코드를 이해하기 쉽고 데이터 추적과 디버깅이 용이

단점

• 여러 데이터가 업데이트되면 이상한 효과를 만들어 React의 렌더링 메소드가 다른 controller-view에 의해 반복적으로 실행되서 디버깅의 어려움을 가중할 가능성
• 변화를 감지하고 화면을 업데이트하는 코드를 매번 작성해야함

 

작동원리

• 데이터가 담겨있는 객체(Action)을 Dispatcher로 전달
  • Dispatcher는 데이터 흐름을 관리하는 허브 / Action이 발생하면 Dispatcher로 전달
• Action에 따라 등록된 콜백함수를 실행시켜 Store에전달
  • Store는 애플리케이션의 모든 상태와 관련 로직을 갖고있음
• Store의 변경상황을 View에 알려줌
  • Flux의 View는 화면에 나타내는 것 뿐만아니라,. 자식의 View로 데이터를 흘려 보내는 View Controller역할도 같이함
• View에서 변경하고 싶을 때에는 Action생성자를 호출

⇒ 정리

• action은 dispatcher를 통해 store의 상태를 갱신
• store가 업데이트 된 후, 상태가 변경되었다는 이벤트를 중계하는 과정으로 view에게 새로운 상태를 보내주고 view스스로 업데이트하게 만듦

 

Action

Action이란 데이터를 변경하는 행위

Dispatcher에게 전달되는 객체를 말한다. Action creator매소드는 새로 발생한 Action의 타입과 새로운 데이터(payload)를 묶어 Dispatcher에게 전달한다

{
  type: 'SET_PROFILE',
  data: {
    'name': 'Harry',
    'age': 458
  }
}

Dispatcher

Dispatcher는 모든 데이터의 흐름을 관리하는 중앙허브

Dispatcher에는 Store들이 등록해놓은 Action타입마다 콜백함수들이 존재한다
Action을 감지하면 Store들이 각 타입에 맞는 Store의 콜백함수를 실행한다
Store의 데이터를 조작하는 것은 오직 Dispatcher를 통해서만 가능
또한 Store들 사이에 의존성이 있는 상황에서도 순서에 맞게 콜백함수를 순차적으로 처리할 수 있도록 관리함

Store (Model)

Store는 상태저장소 / 상태와 상태를 변경할 수 있는 메서드를 가지고 있다
어떤 타입의 Action이 발생했는지에 따라 그에 맞는 데이터 변경을 수행하는 콜백함수를 Dispatcher에 등록
Dispatcher 에서 콜백함수를 실행하여 상태가 변경되면 View에게 데이터가 변경되었음을 알림

View

View는 리액트 컴포넌트라고 생각하면 됨

Store에서 Ciew에게 상태가 변경되었음을 알려주면 최상위 View(Controller View)는 Store에서 데이터를 가져와 자식 View에게 내려보냄
새로운 데이터를 받은 View는 화면을 리렌더링함
또한 사용자가 View에 조작을 하며 그에 해당하는 Action을 생성한다