[1] MVC(Model View Controller)란?
하나의 애플리케이션, 프로젝트를 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴이다. (아키텍쳐)
■ Model: 애플리케이션의 정보, 데이타를 나타낸다. 데이타베이스, 처음의 정의하는 상수, 초기화값, 변수 등을 뜻합니다. 또한 이러한 DATA, 정보들의 가공을 책임지는 컴포넌트를 말한다.
■ View: input 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타낸다. 다시 말해 데이터 및 객체의 입력, 그리고 보여주는 출력을 담당한다. 데이타를 기반으로 사용자들이 볼 수 있는 화면이다.
■ Controller: 데이터와 사용자인터페이스 요소들을 잇는 다리역할을 한다. 즉, 사용자가 데이터를 클릭하고, 수정하는 것에 대한 "이벤트"들을 처리하는 부분을 뜻한다.
[2] 문제점 (양방향, 의존성)
■ facebook의 메시지 알림 버그
facbook에 로그인 했을 때 [화면 위의] 메시지 아이콘에 알림이 떠 있지만, 그 메시지 아이콘을 클릭해서 들어가보면 아무런 메시지가 없던 적이 있었을 것이다. 알림은 사라지겠지만, 몇 분 뒤 알림이 다시 나타나고 여전히 아무런 메시지도 나타나지 않는다. 그리고 이 사이클(cycle)은 계속 반복된다.
■ 페이스북 알림 기능의 흐름 (챗 탭 only)
1. 새 메시지: 새 메시지 도착(Model) → 알림 아이콘에 "1" 추가(View) → 챗 탭(View/Controller)에 메시지 노출
2. 읽은 매시지: 챗 탭에 포커스(Controller) → 알림 아이콘 "1" 감소(View) → 사용자의 알림상태 업데이트(Model)
※ 챗 탭 하나만 있을때는 MVC 패턴을 이용해도 문제가 없다.
■ 페이스북 알림 기능의 흐름 (챗 탭, 메인 메시지 뷰)
- 메인 메시지 뷰가 추가되었다.
1. 새 메시지: 새 메시지 도착(Model) → 알림 아이콘에 "1" 추가(View) → 챗 탭(View/Controller) & 메인 메시지 뷰(View/Controller)에 메시지 노출 & 메인 메시지 뷰에 채팅 목록 노출(View/Controller)
2. 읽은 매시지: 챗 탭 or 메인 메시지 뷰에 포커스(Controller) → 알림 아이콘 "1" 감소(View) → 사용자의 알림상태 업데이트(Model)
※ 새로운 메시지가 도착하면 메시지 핸들러는 챗 탭과 메인 메시지 뷰에게 새로운 메시지를 추가하라는 명령을 내리고, 알림 메시지에게는 1 증가시키도록 한다. 그리고 메인 메시지 뷰에는 사용자의 채팅 목록을 보여준다. 마지막으로 챗 탭과 메인 메시지 뷰에서 새 매시지를 읽었을 경우, 알림 메시지를 1 감소시키도록 명령하는 역할을 하고 있다.
메시지 핸들러는 추가/감소, 목록 노출, 메시지 노출 기능을 수행하고 있다. 기능이 추가되고 확장됨에 따라 메시지 핸들러는 더욱 복잡해져 유지보수가 어려울 것이다.
※ 메인 메시지 뷰가 추가됨에 따라 MVC패턴은 위와 같은 형태가 되었다. 새로운 기능이 추가될 때 마다 MVC패턴은 위와 같이 복잡한 형태가 되면서 데이터의 흐름을 파악하기 어려워지고 그러면서 유지보수도 점점 더 어려워진다.
※ MVC 패턴은 Model, View, Controller는 서로에 대한 의존성을 가지고 데이터의 흐름이 양방향이기 때문에 기능이 많은 어플리케이션에서는 코드의 흐름, 데이터의 흐름을 파악하기 어려워 지는 단점이 있다.
리액트는 MVC 패턴을 사용하지 않는다. (VIEW만 담당한다)
[1] Flux란?
- Flux는 애플리케이션 내의 데이터 흐름을 단방향(single directional data flow)으로 흐를 수 있도록 도와주는 시스템 아키텍처다.
■ Action: AJAX, View에서 발생한 상태 변경요청을 담은 자바스크립트 객체이다.
- 이 객체는 액션 이름(type)과 데이터(payload)를 담고있고 Dispatcher에게 전달된다.
■ Dispatcher: 액션을 모든 스토어에게 전달하는 전달자이자 교통정리 시스템이다.
- View로 부터 Action을 받아 모든 Store에게 순서대로 전송한다.
- 내부에 상태 변경 로직이 존재하지 않는다. (순수함수: 외부의 영향을 받지 않는다.)
■ Store: 상태변경 로직과 어플리케이션의 상태가 저장되어 있는 전역 저장소이다.
- Dispatcher에서 전달된 Action을 통해서만 상태 변경이 가능하다.
- 자신이 가지고 있는 상태에 관심있는 View에게 변경된 상태를 통지한다.
■ View: 관심있는 어플리케이션 상태가 변경될때 마다 다시 그려지는 컴포넌트이다.
- MVC 패턴에서 Controller-View의 역할을 한다.
- Store가 통지하는 상태 변경을 수신, 받은 상태에 따라 View를 새로 렌더링한다.
- Dispatcher에게 Action을 전달할 수 있다.
[2] 장점
1. 데이터 흐름의 구조화 - 기능별 분리처리가 잘되어 있어 코드의 흐름을 파악하기 쉽다. 그렇기 때문에 유지보수가 쉽고 새로운 기능확장에 열려있는 어플리케이션을 만들 수 있다.
2. 쉬운 유닛 테스트 - Dispatcher는 순수함수로써 외부 상태의 영향을 받지 않는 격리된 환경에서 쉽게 테스트할 수 있다.
[3] 단점
1. 높은 학습곡선 - 작은 기능들을 각각 정의하고 분리해야 하기 때문에 상대적으로 많은 코드가 필요하다.
위 facebook 알림 기능을 FLUX패턴으로 정의한다면...
- 새로운 메시지가 도착한 뒤 각 View가 어떠한 기능들을 받아 수행될지 세분화 해보면,
1) 메시지 추가
2) 전체 메시지 상태
3) 읽지 않음 카운터
세분화된 기능에 따라 Store를 만들고, View들은 각각의 Store에 저장되어 있는 자신이 관심있어하는 상태를 바라보게 되어 상태가 변경됨에 따라 자동으로 자신을 렌더링할 수 있도록한다.
이제 Store가 있으니 사용자의 요청(Action)을 전달해야 하는 전달자가 필요하다. 3가지 기능에 따라 3개의 Store가 있으니, 사용자의 Action도 3가지이다. 각각 요청에 맞게 Dispatcher라는 전달자를 통해 Store의 상태를 변경시키도록 한다.
이렇게 데이터의 흐름을 단방향으로 수정하고 보니 FLUX 패턴과 똑같이 생긴 것을 알 수 있다.
댓글