[React] 디자인 패턴 (MVC, Flux)

디자인패턴

: 어플리케이션 설계 중 자주 발생하는(되풀이되는) 문제에 대한 모범답안

 

즉, 프로그램을 개발하면서 생기는 문제를 해결하는 모법답안을 말한다. 

 

 

 

 

디자인 패턴을 사용하는 이유?

- 검증된 해결책 : 이미 검증된 방식 및 방법으로 해결방안을 찾을 수 있음 -> 효과적으로 코드 개선

- 효율적인 소통방식 : 거대하고 복잡한 코드는 규모가 작을때부터 체계적인 규칙이 필요하다. ->  매번 디테일한 설명을 거치지 않고, 사전에 약속해둔 용어들로 표현할 수 있도록 해준다.  -> 의미를 명확하고 효율을 높이고, 체계적인 코드를 만들 수 있음 

- 유지보수 용이 : 각각 기능을 담당하는 영역을 분리(관심사별로) 헤서 관리할 수 있도록 설계됨 -> 필요한 부분만 수정 가능

 

 

 

 

- 상대적으로 코드 레벨에 가까운 디자인 패턴들

- 어플리케이션 전체의 아키텍쳐 레벨에 좀 더 가까운 디자인 패턴들도 있음

 

 

 

 

 

아키텍쳐 레벨에 가까운 대표적으로 쓰이는 2 가지 패턴

---

1. MVC (model-view-controller)

프로젝트 구성요소를 역할에 따라 model, view, controller 이 3가지 구조로 나눠서 관리하는 패턴

* Model : 정보 및 데이터를 관리하는 역할 ( React 에서는 state) 

* View : 브라우저 화면 , 사용자 인터페이스 요소 담당 (React 에서는 jsx)

* Controller : 사용자의 Action에 의해 이벤트를 감지하고 처리하는 역할 (Model, View를 업데이트 하는 로직 포함) 

 

ref from westudy) MVC 패턴

 

Flow) 

- Controller는 Model과 View 사이에서 필요한 로직을 처리함

: View에서 User의 Action이 발생->  Controller로 해당 액션이 전달 -> Controller에서 필요한 로직 처리 후 Model에 접근해 데이터 수정 , 수정된 데이터를 다시 View에게 전달하여 화면을 업데이트 함

 

or

 

- 만약 데이터를 수정할 필요 없이 그냥 바로 View만 변경하면 될 경우,

: Controller가 Model에 접근하지 않고 바로 View를 조작하는것도 가능

 

or

 

- 만약 Controller에서 처리해야할 중간 로직이 없다면, 

View와 Model이 서로에게 접근해서 수정하는것 또한 가능

 

 

 

 

장점) 관심사의 분리 (Soc, Separation of Concern)

- 각 부분별로 어떤 역할을 하는지 분명해짐.

- 한 파일 안에서 의존도를 낮게 관리할 수 있음 -> 문제발생시 빠르게 확인 후 처리가능  = 유지보수 용이

 

 

 

 

한계)

MVC 양방향 데이터 흐름의 한계

프로젝트 단위가 커지는 경우, Model과 View가 늘어나게 되는데, 이 때 Model과 View는 서로 의존하고 있기 때문에 하나의 Model에  여러개의 View가 연결되어 있기도 하거나 반대인 경우도 있을 수 있음.

=> 양방향 데이터 흐름을가지고 있어서 연쇄적인 데이터 변화가 발생할 수 있음  (Model과 View의 업데이트 예측이 어려워 짐) 

 

 

 

이를 해결하기 위한 새로운 디자인 패턴 탄생 !!

 

 

 

 

2. Flux  (data flow : 한 방향)

Action, Dispatcher, Store, View 네 가지의 구조로 나눠서 관리함

 

생긴이유? )

 

- 여러 View에 여러 Model들이 의존하고, 양방향으로 데이터를 주고받는 MVC는 애플리케이션의 동작을 예측하기 어려워짐 -> 이런 예측하기 어려운 양방향 데이터 흐름 (Bidirectional data flow)을 보완하기위해 Facebook에서는 단방향 데이터 흐름 (Unidirectional data flow) 패턴인 Flux를 제시했음.

FLUX 패턴 구조 및 Flow

 

 

* Action : 어떤 변화를 일으키고 싶은지 설명하는 단순한 자바스크립트 객체 

이벤트 구독, 이벤트 발생 시 Action 객체를 만들어서 Dispatcher 에 전달하는 역할을 하는 Action Creator 역할

* Dispatcher : Action을 Store에 배분해 줌. (복잡한 로직 x, flux의 중앙hub역할) 

Action 객체의 type property에 따라 Store에 어떤 행동을 할지 결정하는 역할로, Store의 콜백을 등록할 때 쓰이며, 

* Store : 데이터의 저장소 역할 (Dispatcher로 전달받은 Action에 따라서만 데이터 변경함. 그 외의 변경은 허용하지 않음)

 

* View : 데이터를 UI로 표현하는 역할 ( Store를 구독하고 있다가 데이터가 변경되면 UI에 반영)

Store의 상태에 따라 화면에 그려지는 부분

 

 

 

 

Flow)

이벤트가 발생하면, Dispatcher에게 생성된 Action 객체를 전달 -> Dispatcher에서 Action 객체의 type property에 따라 Store상태 업데이트 ->업데이트 된 store에 따라 View (화면에 그려줌) 

 

 

이 때, 이 구조라면 Action에서 시작해 View로 끝나는 data flow라고 생각 될 수 있지만, 

이렇게 마지막 View에 다다르고 화면이 랜더링 되면 View에서 새로운 Action 객체를 만들어서 시스템에 전파하여 업데이트 된 내역을 알게 한다. => 데이터는 한방향으로 흐름 / 각각 구조가 서로 의존 하지 않음 => 데이터 구조 파악과 흐름을 예측하기 용이함 

 

 

 

 

 

 

이거..면접에 나왔었다..이제서야 공부했다... 🥲