SEB Section 2 Flux

Redux를 배우기 전에 Redux의 디자인 패턴을 먼저 알아야 할 것 같다. 먼저 기존의 디자인 패턴에 대해 알아보자.

MVC 패턴

Front-End에서 사용되는 프레임워크의 대부분은 MVC(Model-View-Controller) 디자인 패턴을 채택했었다. 각 명칭의 기능을 알아보자.

• Controller

Controller는 Model의 데이터를 조회하거나 업데이트를 하는 역할을 한다.

• Model

Model은 데이터를 담고 있으며 모델의 값인 View에 반영이 된다.

• View

View를 통해 데이터를 입력하면, 즉각 모델에 영향을 주면서 데이터를 관리하게 된다. View는 실제 유저가 보는 UI에 해당된다.

이렇게 관리를 하게 되면 각자의 역할에만 충실하게 할 수 있어, 효율적으로 실행이 되고, 유지보수성이 높아지고, 확장성, 유연성 등 많은 장점을 가지고 있다.

하지만 MVC 패턴에서도 문제점이 생긴다.

MVC 패턴의 문제

문제는 대규모 애플리케이션의 경우 MVC가 너무 빠르고 복잡해 진다는 점에 있다. 그래서 코드 예측이나 테스트의 어려움, 유지보수 비용 증가 등 여러가지 문제가 발생한 것이다. 가장 대표적인 사례로 페이스북의 안 읽은 글 갯수 표시인데, 사용자가 읽지 않았던 글을 읽으면 그만큼 숫자를 빼는 단순한 기능임에도, MVC로 구현하게 되었을 때 모델별로 데이터를 가지고 있는게 달랐기 때문에 이것들을 싱크하거나 동시 업데이트 해야해서 매우 불편한 관계가 있었던 것이었다.

그래서 React는 Flux 아키텍처를 적용할 수 있게끔 한다.

Flux란?

Flux 아키텍처의 가장 큰 특징으로는 ‘단반향 데이터 흐름’을 들 수 있다. React의 데이터 흐름과 비슷하다. 데이터의 흐름은 언제나 Action에서 Dispatcher에서 Store로, 스토어에서 View로 흐르게 된다. 만약 View에서 사용자의 입력이 있는 경우, 상태를 변경을 해야 하니, View에서 Action을 호출하여 Dispatcher로, Dispatchere에서 Store로 흐르게 될 것이다.