Flux 그전에 MVC

Flux를 하기 전에 MVC를 안 하면 찝찝할 거 같아서 MVC부터 보련다. 길게 다 정리하고 싶다만 그건 구글에 넘쳐서 나는 내 생각 정리나 해야겠다.

MVC 정의부터 보고 가자 모질라에서는 다음과 같이 말한다

MVC
 (모델-뷰-컨트롤러) 는 사용자 인터페이스, 데이터 및 논리 제어를 구현하는데 널리 사용되는 소프트웨어 디자인 패턴입니다. 소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 두고 있습니다. 이러한 "관심사 분리" 는 더 나은 업무의 분리와 향상된 관리를 제공합니다. MVC에 기반을 둔 몇 가지 다른 디자인 패턴으로 MVVM (모델-뷰-뷰 모델), MVP (모델-뷰-프리젠터), MVW (모델-뷰-왓에버) 가 있습니다.
모델: 데이터와 비즈니스 로직을 관리합니다.
뷰: 레이아웃과 화면을 처리합니다.
컨트롤러: 명령을 모델과 뷰 부분으로 라우팅합니다.

그니까 비즈니스 로직과 화면을 구분해서 만드는 패턴이라는 것. 다른 글들에서는 이렇게 분리시킴으로써 서로 영향 없이 개발할 수 있게 해준다고 한다. 각 요소들이 어떻게 작동하는지 간단하게 보자

그럼 model, view, controller의 역할을 각각 알아보자. 

모델은 앱이 포함해야 할 데이터가 무엇인지 정의하고, 상태가 변경되면 그걸 뷰에게 알리거나 때때로 컨트롤러에게 알린다. 여기서 모델은 뷰나 컨트롤러에 대한 정보를 알고 있지 않아야 각 요소가 이상적인 MVC패턴으로 구현될 수 있다고 한다. 변경 사항이 일어나면 이벤트를 발생시켜 다른 요소에게 알림

뷰는 앱의 데이터를 보여주는 방식을 정의한다. 사용자가 실제로 화면에 보는 인터페이스를 담당한다.  UI 변경이 일어났을 때, 직접 변경하지 않고 이를 이벤트화 해서 다른 요소에 전달시킬 수 있는 방법을 가지고 있는다.

컨트롤러는 모델과 뷰를 중개하는 역할을 하는데, 위에서 모델이나 뷰가 변경사항을 전달해서 그걸 처리하는 게 controller가 하는 일이다. 컨트롤러는 모델이나 뷰에 대한 정보를 알고 있어야 한다. 

아무튼 Flux가 나오게 된 계기를 설명하려면 이 MVC의 한계를 알아야 하기 때문에 적당히 하고 바로 한계로 넘어가자.

MVC의 핵심은 각 구성요소를 독립시킴으로써 각 팀으로 하여금 맡은 부분의 개발에만 따로 집중할 수 있게 하여 개발의 효율성을 높일 뿐만 아니라. 개발 완료 후에도 유지보수성과 확장성을 보장한다.

그런데 이게 앱이 커지면 문제가 생긴다. 구조상 컨트롤러가 중재를 하는데 앱이 커지면서 다수의 모델과 다수의 뷰가 생겨나면서 복잡하게 연결되는 상황이 생길 수 있다. 이러면 코드 분석이나 테스트가 어렵다고 한다.

위의 문제점을 해결하기 위해 여러 패턴들이 나왔는데 여기서 알아볼 건 Flux다.

Flux도 크게 세 부분으로 구성이 되는데, 각각 디스패처, 스토어, 뷰이다.

이 Flux의 가장 큰 특징은 단방향 데이터 흐름이라고 한다.  데이터 흐름이 언제나 디스패처 -> 스토어 -> 뷰 -> 액션-> 디스패처 이렇게 흐른다. 뷰에서 사용자의 입력이 있는 경우 뷰는 액션을 호출한다. Flux의 단방향 데이터 흐름은 데이터 변화를 훨씬 더 예측하기 쉽게 해준다고 한다.

 

 

각 요소들이 무슨 동작을 하는지 알아보자 

액션은 액션 생성자라고 하는데, 애플리케이션의 상태를 변경하거나 뷰를 업데이트하고 싶다면 액션을 생성해야 한다고 한다. 무슨 메시지를 보낼지 알려주면 액션 생성자는 나머지 시스템이 이해할 수 있는 포맷으로 바꿔준다. 액션 생성자는 타입과 페이로드를 포함하는 액션을 생성해서 디스 패쳐로 넘겨준다. 디스 패쳐는 기본적으로 콜백이 등록되어있는 곳이다. 디스 패쳐는 액션을 보낼 필요가 있는 모든 스토어를 가지고 있고, 액션이 넘어오면 스토어로 보낸다. 여기서 다른 아키텍처와 다른 게, 액션 타입과는 관계없이 등록된 모든 스토어로 액션이 보내진 다는 것이다.  즉, 스토어가 특정 액션만 구독하지 않고 일단 모든 액션을 받은 뒤에 처리할지 말지를 결정한다는 뜻이다.

스토어는 애플리케이션 내의 모든 상태와 그와 관련된 로직을 가지고 있다. 모든 상태 변경은 반드시 스토어에 의해서 결정되어야 하고, 스토어에 직접 보낼 수 없고 앞서 이야기한 과정을 거쳐서 액션을 보내야만 한다. 스토어의 내부에서는 보통 switch statement를 사용해서 처리할 액션과 무시할 액션을 결정하게 된다. 만약 처리가 필요한 액션이라면, 주어진 액션에 따라서 무엇을 할지 결정하고 상태를 변경하게 된다.

일단 스토어에 상태 변경을 완료하고 나면, 변경 이벤트(change event)를 내보낸다. 이 이벤트는 컨트롤러 뷰(the controller view)에 상태가 변경했다는 것을 알려주게 된다.

뷰와 컨트롤러 뷰, 뷰는 상태를 가져오고 유저에게 보여주고 입력받을 화면을 렌더링 하는 역할을 맡는다. 컨트롤러 뷰는 스토어와 뷰 사이의 중간관리자 같은 역할을 하는데 상태가 변경되었을 때 스토어가 그 사실을 컨트롤러 뷰에게 알려주면, 컨트롤러 뷰는 모든 뷰에게 새로운 상태를 넘겨준다. 

동작하는 구체적인 과정은 밑에 블로그에 자세하게 나와있으니 꼭 참고하면 좋겠다. 정말 보기 쉽게 되어있다.

위에서 참 열심히 정리를 해봤는데, 실제로 페이스북에서 Flux 구현체도 공개했는데 완전한 Flux 프레임워크라고 보기엔 무리가 있다고 한다. 그 대신 그와 비슷한 구현체들이 등장했다고 한다. 그중에 하나가 바로 Redux이다. 이 리덕스는 다음에 정리해야겠다

 

정리해보자면 MVC패턴을 사용한 앱들이 규모가 커지면서 다양한 모델과 뷰의 중개역할을 하는 컨트롤러의 부담이 심해졌다. 그래서 나온 패턴 중 하나인 Flux는 단방향 데이터 흐름을 큰 특징으로 가지고 있는데, 페이스북에서 생겼던 문제 중에 양방향 데이터 바인딩이 되어있어서 모델을 업데이트 한 뒤 다른 모델을 업데이트해야 하는 순차적인 업데이트가 발생을 하고 그에 따라 결과 예측을 어렵게 한다는 것이다.  Flux 구조는 이런 문제를 해결하였고 , 이 구체적인 구현체 중 하나가 Redux이다.

 

 

참고:  https://developer.mozilla.org/ko/docs/Glossary/MVC

MVC - 용어 사전 | MDN

https://m.blog.naver.com/tlstjd436/222010976665

[디자인패턴] MVC 패턴이란?

 

https://haruair.github.io/flux/docs/overview.html

Flux | Flux

 

https://bestalign.github.io/translation/cartoon-guide-to-flux/

Flux로의 카툰 안내서

https://taegon.kim/archives/5288

Flux와 Redux