Design Pattern의 종류
1. MVC
- 프로젝트의 구성요소를 역할에 따라 Model, View, Controller 세가지로 나눠서 관리하는 패턴
-> Model은 데이터를 관리하는 역할
-> View는 사용자에게 보여지는 UI를 담당
-> Controller는 사용자의 Action에 의해 이벤트를 감지하고 처리하는 역할 즉, Model 또는 View를 업데이트하는 로직을 담당
- 각 구성요소들의 관심사의 분리(SoC, Seperation of Concern)가 잘 이루어져있기에 유지보수 및 확장이 용이함
- controller는 Model과 View 사이에서 필요한 로직을 처리
-> View에서 User의 Action이 발생하면, Controller로 해당 액션이 전달되고, Controller에서 필요한 로직을 처리 후 Model에게 접근해 데이터를 수정, 그리고 수정된 데이터를 다시 View에게 전달해서 화면을 업데이트! - 데이터를 수정할 필요 없이 그냥 View만 변경하면 될 경우에는 Controller가 Model에게 접근하지 않고 바로 View를 조작하는 것도 허용
- 데이터를 이용한 중간 처리 로직이 필요없을 경우 Model에서 Controller를 거치지 않고 바로 View에게 데이터의 변경을 알리는 것도 허용
- MVC패턴의 한계점
-> 프로젝트 단위가 커지면, Model과 View가 자연스럽게 늘어난다. 모델과 뷰는 서로 의존하는 양방향의 데이터 흐름을 가지고 있기 때문에 View와 Model의 업데이트는 예측 하기 어려워진다.
2. Flux
- 예측하기 어려운 양방향 데이터 흐름(Bidirectional data flow)을 보완하기위해 Facebook에서 나온 단방향 데이터 흐름(Unidirectional data flow)패턴
- Flux는 Action, Dispatcher, Store, View 네가지 구조로 나눠서 관리 한다
-> Action은 이벤트를 구독하고 있다가 이벤트 발생 시 Action 객체를 만들어서 Dispatcher에 전달하는 역할을 하는 Action Creator의 역할을 한다
-> Dispatcher는 Action 객체의 type property에 따라 Store에 어떤 행동을 할지 결정한다. Store의 콜백을 등록하는데 쓰이고, Action을 Store에 배분해준다. 복잡한 로직이 있지 않고 Flux의 중앙 허브역할을 한다
-> Store는 상태를 저장하는 저장소의 역할을 한다. 그리고 상태를 변화시키는 로직을 가지고 있다
-> View는 Store의 상태에 따라 화면에 그려지는 부분이다.
-Flux의 데이터 흐름은 한 방향으로 흐른다.
이벤트가 발생하면, Dispatcher에게 생성된 Action 객체를 전달한다. Action 객체를 전달받은 Dispatcher에서 Action객체의 type property에 따라 Store의 상태를 업데이트하고, View는 업데이트 된 State에 따라 화면에 그려지는 플로우로 진행된다.
- 마지막 View에 다다르고 화면이 렌더링 되면 View에서 새로운 Action 객체를 만들어 시스템에 전파해 업데이트 된 내역을 알게 한다. 결국 데이터는 한쪽 방향으로만 흐르게 되고, 각각의 구조는 서로 의존하지 않고 있어 데이터의 구조파악과 흐름을 예측하기 비교적 용이하다. 디버깅에도 어떤 부분의 오류인지 찾아가기 수월한 장점이 있다.
