본 글은 http://haruair.github.io/flux/ 를 참고하여 작성되었습니다.
MVC와 Flux 모두 Design-pattern의 일종이며 개발에 기반이 되는 일반적으로 널리 알려진 패턴이다.
MVC(Model-View-Controller)
MVC는 Model, View, Controller의 약자이다. 이는 하나의 프로젝트를 구성할 때 필요한 구성요소를 세가지의 역할로 구분한 것이다. MVC 에서는 controller는 model의 데이터를 조회하고 업데이트 하며, model의 변화는 view에 반영되어 나타나게 된다.
동작의 sequence는 아래와 같은 흐름으로 일어난다.
1. 사용자가 View를 통해 Action을 일으키고 이를 Controller가 확인한다.
2. Controller는 Action을 확인하고, 이에 알맞게 Model을 업데이트시킨다.
3. Controller는 업데이트된 Model을 나타내줄 View를 선택하고
4. View는 건네받은 Model 데이터를 이용해 화면을 나타냅니다.
이 패턴의 큰 특징은 사용자 인터페이스로부터 비즈니스 로직을 분리하여, 애플리케이션의 시각적 요소와 내부에서 구현되어 있는 비즈니스 로직을 서로 영향을 받지 않고 관리할 수 있다는 것이다. 따라서 확장성과 유연성이 높은 코드 형태가 된다. 또한 양방향으로 소통한다는 특징이 있는데, 이것이 단점으로 작용하기도 한다.
각 구성요소들을 자세히 알아보자
Model
우리가 일반적으로 생각하는 데이터라고 단순하게 생각할 수 있다. 넓은 범주에서 보게 된다면 Back에서 동작하는 로직까지 포함한다. 데이터를 가진 객체일 수도 있으며 일반적으로는 DB라고 생각해도 큰 무리는 없다.
- model 수정에 대한 요청이 들어왔을 때 이에 대응하는 처리방법을 구현해야 한다.
view
사용자가 시각적으로 보는 화면이라고 생각하면 된다. 사용자가 직접 데이터를 입력하거나 버튼, 체크박스 등을 통해 조작할 수 있으며, 받아온 데이터를 출력해주는 역할을 한다.
- 변경이 일어나면 변경을 알려주는 로직을 구현해야 한다. 즉 화면에서 조작을 통해 변경 event가 발생하면 model에게 까지 그 사실을 알려주기 위한 변경 통지를 구현해야 한다.
controller
view를 통해 event를 건네받고 이에 상응하는 model을 찾아 조작한다. 즉 애플리케이션의 로직이 구현되어 있는 곳이다. view와 model을 연결해주는 Bridge 역할을 한다.
- model과 view에 대하여 알고 있어야 한다.
- model과 view를 monitoring 해야한다.
model이나 view의 변경 사항을 받아서 각각의 구성요소에게 알려주는 역할을 한다. 따라서 애플리케이션의 메인 로직은 controller에 존재하게 된다.
예시
이해를 돕기 위하여 간단히 Django의 예를 들어보겠다. 단 이름의 현혹되지는 말아야한다. Django에서 등장하는 3가지 요소는 Model, Template, View가 된다.
- Django의 Model = MVC의 M
class로 표현되며 DB의 하나의 Table이라고 생각하면 편하다 - Django의 Template = MVC의 V
HTML로 구현되면 view에게 받은 데이터를 동적으로 적용한다. - Django의 View = MVC의 C
접속한 url과 method에 따라 요청한 데이터를 Model에서 가져오고, 그 데이터를 view(Template)로 전달해준다.
단점
앞서 언급했듯이 양방향 바인딩이라는 점이 단점으로 작용할 수 있다. 결국 MVC의 경우 model의 변화가 view를 변화시킬 수 있고, view의 변화 또한 model의 변화를 일으킬 수 있다. 이러한 경우 아래와 같이 단위가 큰 어플리케이션의 경우 하나의 model을 업데이트 하는 것으로 예상치 못한 많은 view에서의 업데이트가 수반될 수 있다.
이러한 단점을 포착한 Facebook 에서 Flux를 제안한다!!
Flux
Facebook에서 MVC pattern의 한계점을 극복하고자 새로운 단방향 데이터 흐름의 만들어 냈다. MVC의 큰 특징이자 단점이 될 수 있는 것은 양방향 데이터 흐름이며 이를 극복하고자 단방향 데이트 흐름을 갖는 Flux가 등장한 것이다.
Flux는 크게 Action, Dispatcher, Store, View로 구성되어 있으며 구조와 흐름은 다음과 같다.
- 대부분의 action은 view에서의 user interaction으로 발생하며 dispatcher로 전달된다.
- dispatcher는 전달받은 action을 callback을 통해 모든 store에 전달한다.
- store에서는 자신이 관리하는 state가 관련된 액션이 감지되면 내부에 구현된 로직에 맞춰 state를 업데이트 시킨다.
- store는 업데이트 이후 change event를 emit 한다.
- controller-views 라는 특별한 view들이 이를 감지하여 state를 새로 받아와 전체 view에 제공해주게된다.
각 구성요소들을 자세히 알아보자
actions
새로운 데이터를 포함하고 있는 간단한 객체로, type 프로퍼티를 지니며 이를 통해 구분된다. 이러한 action의 생성은 action creator method를 통해 이뤄지며 dispatcher로 action을 보낼 때 이 creator method를 제공한다.
모든 action은 store가 dispatch에 등록해둔 callback을 통해 모든 store에 전송된다.
dispatcher
dispatcher는 Flux 어플리케이션의 중앙 허브로 모든 데이터의 흐름을 관리한다. 가장 큰 역할은 store의 콜백을 등록하고, action을 모든 store에 배분해주는 일이며, 이는 단순하지만 아주 중요한 역할을 한다.
store
store는 어플리케이션의 state와 logic을 모두 포함하고 있다. 하나의 특징을 꼽자면 어플리케이션 내의 개별적인 domain별로 state를 분리하여 관리한 다는 것이다.
store는 자신을 dispatcher에 등록하여 callback을 제공하고, callback을 통해 건네받은 action을 callback 내부의 switch문에 따라 type을 확인하여 적절하게 state를 업데이트 시킨다. 업데이트된 이후에는 view에게 새로운 상태를 보내 스스로 업데이트 하게 만든다.(controller-view 이용)
view
flux에서의 view는 MVC에서의 view의 역할에만 국한되는 것이 아니라 controller의 성격도 갖고 있다. 특히나 최상위 view(controller-view)의 경우 스토어에서 state가 change된 것을 감지하여 state를 새로 불러오고, 이를 하위 view 들에게 내려보내주는 역할을 한다.
