Flux Architecture 등장 배경

Flux 는 기존 MVC 패턴의 단점을 보완하고자 Facebook 에서 개발한 아키텍쳐이다.
기존 MVC 패턴에 무슨 문제가 있길래 Flux를 개발했을까?

기존 MVC 패턴을 알아보자

MVC는 Model-View-Controller 의 약자이다. 소프트웨어의 비즈니스 로직 과 화면 을 구분하는데 중점을 두고 있는 디자인 패턴이다.

MVC 는 3가지 부분으로 구성되어 있다.

• Model : 데이터와 비즈니스 로직을 관리한다.
• View : 레이아웃과 화면을 처리한다.
• Controller : 모델과 뷰로 명령을 전달한다.

MVC 패턴에 무슨 문제가 있길래 Flux를 개발하였을까?

이런 로직에서의 문제는 거대한 프로젝트에서는 너무 복잡해진다는 점이다.

이런 문제점을 해결하기 위해 Flux 구조가 등장하였다.

Flux Architecture란

Flux 는 Facebook에서 만든 디자인 패턴이다.

구조와 데이터 흐름

Flux에서 데이터는 단방향 으로 흐른다.
단방향 데이터 흐름은 Flux의 핵심이며, Flux 프로그래머를 위한 제일의 멘탈 모델 이 된다.

데이터의 흐름은 Dispatcher -> Store -> View 순서이며 View 에서 입력이 발생하면 Action 을 통해 Dispatcher 로 간다.

그럼 지금부터 Action , Dispatcher , Store , View 에 대해서 자세하게 알아보자

1. Dispatcher

모든 데이터는 중앙 허브인 Dispatcher를 통해서 흐른다.
본질적으로 Store의 콜백을 등록하는데 쓰이고 Action을 Store에 배분해주는 간단한 작동 방식을 가진다.

2. Store

Store는 애플리케이션의 상태를 저장하는 역할을 한다.
모든 상태 변화는 Store를 통해 일어나며 Dispatcher 단계를 거쳐야지만 상태값 변경 요처이 가능하다.

3. Action

Dispatcher를 통해 Store에 상태 변화 요청을 보낼 수 있는데 이때 Dispatcher의 데이터 묶음 을 Action 이라고 한다.

4. View or Controller-View

View는 Store에서 상태를 가져와서 사용자에게 보여주는 역할을 한다.
Controller-View 는 Store와 View의 중간 관리자 같은 역할을 하는데 Store에서 일어난 상태 값의 변경을 자신 아래의 모든 View에게 전달해주는 역할을 한다.

마무리

Flux 디자인패턴에 대해 공부해 보았다. MVC 구조는 알고 있었지만 Flux 구조는 처음 들어보는 거라 생소했다.
공부하면서 Flux의 장점에 대해 알게 되었고, 실제로 프로젝트에도 적용해 보고 싶다는 생각을 했다.
MVC와 Flux 말고도 다양한 디자인 패턴들이 있는데 나중에 시간이 나면 한번 공부해 봐야겠다.