MVC 패턴
Model-View-Controller의 약자이며,
개발할 때, 역할을 나누는 방법론 중의 하나이다.
필요성과 구조
앱을 만들 때, 일어나는 과정을 간단하게 요약해서 살펴보면
- database를 만들고
- data를 읽고 쓰고 수정하고 삭제하고
- 그것을 보여준다.
의 과정을 거치게 되는데 만약 이 로직들이 한꺼번에 정의가 되어있다면, 나중에 유지보수를 할 때 굉장히 곤란한 상황에 처할 수 있다. 이런 이유로 인해 만들어진 것이 MVC 패턴이다.
user가 controller를 조작하면,
controller는 model을 통해서 데이터를 가져오고,
그 정보를 바탕으로 view를 업데이트 하고,
그 view를 다시 user가 보게 되는 구조이다.
Model, View, Controller
- Model
애플리케이션의 정보, 데이터를 나타내며, 데이터 변경이 일어났을 때 Model에서 직접 View나 Controller의 역할을 대신해서는 안된다. 또한, 변경이 일어났을 때 변경통지에 대한 처리방법을 구현해야만 한다. - View
UI요소들을 나타내며, 데이터 및 정보의 출력을 담당한다. 직접적으로 사용자가 볼 수 있는 공간이며 View 역시 변경이 일어났을 때 변경통지에 대한 처리방법을 구현해야 한다. - Controller
Controller는 위에 말한 Model과 View를 연결하는 다리 역할을 한다. Model과 View는 변경 사항에 대해 알리고, 변경사항을 받는 것만 알 수 있는데, Controller는 양쪽을 모두 알고있는 상태에서 서로의 변경 사항을 전달해주는 역할을 한다.
장점
사용자가 보는 페이지, 데이터처리, 그리고 이 2가지를 중간에서 제어하는 컨트롤, 이 3가지로 구성되는 하나의 애플리케이션을 만들면 서로의 로직이 혼선될 역할이 없어진다. 즉, 각자의 역할에 집중할 수 있게 된다.
이를 통해 유지보수성이 좋아지고, 확장성도 좋아질 수 있다.
그러나......페이스북에서 MVC의 단점을 지적하게 되는데...
Flux 패턴
MVC 패턴의 문제점 : 양방향 데이터 흐름
MVC패턴에서 각각의 역할을 수행하는데, 애플리케이션의 규모가 커지고, Model의 수가 많아지게 되니까 예측하기 어려운 버그들이 나오게 되었다.
View의 변경이 Model을 업데이트하게 되고, 그 Model이 다른 View를 업데이트하게 되고, 또 다른 View가 다시 변경되고, 다시 Model을 변경하게 되고........
실제로 페이스북에서는 알림이 뜨는데, 실제로는 안에 알림이 하나도 없는 일명 "알림 버그" 가 발생했고, 그걸 수정하는 업데이트를 해도 또 다른 업데이트로 인해 다시 "알림 버그"가 발생하는 경험을 겪게 되었다.
필요성과 구조
이런 문제점을 페이스북에서는 양방향 데이터 흐름 때문이라고 보았다. 따라서, 단방향 흐름인 Flux 패턴을 도입하게 된다.
- 데이터가 담겨있는 객체(Action)을 Dispatcher로 전달
- Action에 따라 등록된 콜백 함수를 실행하여 Store에 전달
- Store의 변경 상황을 View에 알려준다.
- View에서 변경하고 싶을때에는 Action 생성자를 호출한다.
Action, Dispatcher, Store, View
-
Action
Action은 데이터의 상태를 변경할 수 있는 명령이다. Action 생성자는 새로 발생한 Action의 타입과 데이터를 Dispatch로 전달한다. -
Dispatcher
전달받은 Action 메세지를 Store에 전달하는 과정을 거친다. -
Store
전달받은 Action 타입에 따라 상태를 변경한다 -
View
View는 Store에서 변경된 데이터를 가져와 모든 자식 뷰에게 데이터를 분배한다.
장점
데이터 흐름이 한 방향으로 강제되기 때문에, 양방향 흐름으로 인한 혼선을 줄일 수 있고, 모든 상태가 스토어에 있음으로 변경 사항을 여러 컴포넌트에 전달하기도 쉽다.
