Flux 패턴

 

이번 글에서는 FLUX라는 패턴에 대해알아보고 등장배경에 대해 알아보겠습니다.

MVC 한계점?

 

MVC에서 View는 Controller에 연결되어 화면을 구성하는 단위요소이므로 다수의 View들을 가질 수 있습니다. 그리고 Model은 Controller를 통해서 View와 연결되어지지만, 이렇게 Controller를 통해서 하나의 View에 연결될 수 있는 Model도 여러개가 될 수 있습니다. 즉, 화면에 복잡한 화면과 데이터 구성이 필요하다면, Controller에 다수의 Model과 View가 복잡하게 연결되어 Massive ViewController(대규모 MVC 어플리케이션)가 되어버립니다.
View와 Model간에도 관계가 복잡하게 연결되어있어서 수정시 테스트가 힘들고, 파악이 어렵기 때문에 여러 Side-Effect를 불러오게 되는 문제점이 있습니다.

 

• 뷰와 모델이 양방향 통신이 가능하므로 하나의 뷰가 모듈을 변경했을 때, 다시 그 모듈이 연관된 뷰들을 갱신하고, 업데이트 된 뷰들이 연관된 모델을 다시 갱신하기때문에, 관계에 대한 추적이 힘들다.
• 앱에 대한 기능 추가 및 변경에 따라 생기는 문제점을 예측하기 힘들다
• 앱이 복잡해 질수록 생기는 추가 업데이트에 관한 작성도 어려워진다.

이러하여 페이스북은 MVC패턴을 이용한 복잡한 어플리케이션에서 나타나는 문제점들을 해결하기 위해 FLUX패턴을 만들어 내었습니다.

Flux 디자인 패턴이란?

Action이 발생하면, Diapacher에서 해당 액션을 받아와 Store에서 저장된 정보에 변경을 하여 View 다시 전될되도록 하는 단방향 데이터 흐름을(unidirectional data flow) 적용시킨패턴입니다.
FLux는 대규모 어플리케이션에서 발생 할 수 있는 MVC패턴의 복잡성을 해결 하기위해 등장하였습니다.

Flux 패턴의 핵심요소

Flux에서는 4가지 핵심요소가 존재합니다. Action, Store, Dispatcher, View

Action

액션은 데이터의 상태를 변경할 수 있는 명령어 카드와 같습니다. 액션 생성자는 새로 발생한 액션의 타입과 데이터 페이로드를 액션 메시지로 묶어 디스패쳐로 전달합니다.

Dispatcher

디스패쳐는 액션 메시지를 감지하는 순간 그것을 각 스토어에 전달합니다. 전달은 콜백 함수로 이루어지며, 등록되어 있는 모든 스토어로 페이로드를 전달할 수 있습니다. 이때 스토어가 서로를 의존하고 있다면 (2개의 스토어) 특정 스토어가 업데이트되기를 기다리게 해주는 waitFor()를 사용할 수 있습니다.

Store

스토어는 어플리케이션의 상태를 변경할 수 있는 메서드를 가지고 있습니다. 어떤 타입의 액션이 날아왔느냐에 따라 메서드를 다르게 적용해 상태를 변경하게 됩니다.스토어에 저장된 데이터는 오직 액션에 의해서만 변경이 되어야 한다. 그래서 공개적으로는 setter들은 존재하지 않고 오직 getter들만 있게 된다.

View

보여지는 분 Vue에 해당되는 부분입니다. 컨트롤러 뷰는 스토어에서 변경된 데이터를 가져와 모든 자식 뷰에게 데이터를 분배합니다. 데이터를 넘겨받은 뷰는 화면을 새로 렌더링합니다.