MVC vs. 플럭스 ? 양방향 vs.단방향?

MVC vs. 플럭스 ? 양방향 vs.단방향?

다음 그림(MVC에 대한 설명)을 보면 단방향 데이터 플로우가 보입니다.

그렇다면 MVC가 플럭스를 정당화하면서 양방향 데이터 흐름을 갖는다고 생각하는 이유는 무엇일까요?

Real MVC와 Pure MVC는 단방향입니다.그것은 질문에 붙여진 위키피디아 도표에서 명확하다.

10여 년 전 Apache Struts와 같은 서버 측 프레임워크가 모델 뷰 프레젠터(MVP) 패턴이라고 불리는 MVC의 변형을 구현했을 때 모든 요청은 컨트롤러를 통과하고 모든 응답은 컨트롤러를 통해 반환되었습니다.다들 계속 MVC라고 불렀어요.웹 고유의 특성으로 인해 요청 또는 업데이트를 전송하지 않으면 모델의 변경 사항을 뷰에 반영할 수 없습니다.따라서 Pure MVC는 구현되지 않습니다.오히려 MVP가 시행된다.

몇 년 전 Angular, Ember, Knocko와 같은 프레임워크가 프런트 엔드에 MVC를 구현했을 때 모델 뷰 모델(MVVM) 패턴이라고 불리는 또 다른 변종 MVC를 구현했을 때 MVC라고 계속 부르는 사람은 거의 없었습니다(그리고 MVC라는 용어는 중요하지 않다는 것을 깨닫고 MVW(W의 약자)는 전혀 구현되지 않았습니다).

React가 탄생했을 때, 그들은 (MVP나 MVVM이 아닌) 순수 MVC를 구현할 기회를 잡았고, 거의 변경되지 않은 플럭스로 이름을 변경했습니다.나는 플럭스가 MVC의 또 다른 변종이라고 느낀다.Flux/React 팀은 MVC가 아니라고 하지만, 저는 두 아키텍처 모두 Flux와 MVC 사이에 많은 패리티가 있다고 생각합니다.

Javascript 프레임워크에서는 MVC가 당신이 설명한 대로 작동하지 않기 때문입니다.UI는 일반적으로 다음과 같이 모델과 양방향으로 통신합니다.

1. View 입력에 사용자 입력
2. MVC 프레임워크는 모델을 업데이트하기 위해 onchange()를 바인딩합니다.
3. Ajax 요청은 새로운 모델 데이터를 가져옵니다.
4. MVC 프레임워크가 모델에 일치하도록 입력 값을 업데이트합니다.

플럭스 아키텍처에서 UI는 유형 및 관련 데이터를 사용하여 디스패처에 대한 독립 액션만 실행합니다. 디스패처는 백그라운드 아약스 메서드가 모델을 업데이트하는 것과 동일한 방식으로 모델을 업데이트합니다.

참고 자료: http://www.thesoftwaresimpleton.com/blog/2013/03/23/client-side-mvc/

"클라이언트 측 MVC는 서버 측 MVC와 완전히 다릅니다."

"우리는 두 물체 사이에 쌍방향 통신을 설정하고 있습니다.."

즉, Person 객체의 firstName 속성값을 입력값 속성에 배선하는 것입니다.

http://guides.emberjs.com/v1.10.0/object-model/bindings/

Ember.js의 바인딩은 뷰와 모델 간뿐만 아니라 모든 개체와 함께 사용할 수 있습니다.

저는 임베디드 개발자로 MVC 패턴을 응용 프로그램에 사용하고 있습니다.어플리케이션이 매우 작고 아키텍처가 거의 단방향 MVC로 설정되어 있습니다.하지만 이 기사를 읽고 클라이언트 측 MVC와 MVC와 FLUS의 차이점에 대해 설명했습니다.

참고 자료: http://www.christianalfoni.com/articles/2015_08_02_Why-we-are-doing-MVC-and-FLUX-wrong

종래의 MVC

|------|  request   |------------|  request   |-------|
|      | ---------> |            | ---------> |       |
| VIEW |  response  |            |  response  |       |
|      | <--------- |            | <--------- |       |
|------|            |            |            |       |
                    | CONTROLLER |            | MODEL |
|------|  request   |            |  request   |       |
|      | ---------> |            | ---------> |       |
| VIEW |  response  |            |  response  |       |
|      | <--------- |            | <--------- |       |
|------|            |------------|            |-------|

플럭스

 COMPONENTS          ACTION CREATORS           STORES

    |----------------------<<<<-------------------|
    |                                             |
|------|            |------------|            |-------|
|      |  request   |            |  request   |       |
| VIEW | ---------> |            | ---------> | MODEL |----
|      |            |            |            |       |   |
|------|            |            |            |-------|   |
                    | CONTROLLER |                        |
|------|            |            |            |-------|   |
|      |  request   |            |  request   |       |   |
| VIEW | ---------> |            | ---------> | MODEL |   |
|      |            |            |            |       |   |
|------|            |------------|            |-------|   |
   | |                                           |        |
   | |--------------------<<<<-------------------|        |
   |----------------------<<<<----------------------------|

MVC라는 용어는 순수 MVC가 아니라 MVP(Backbone), MVVM(Angular 1) 또는 좀 더 광범위하게 MV*로 지칭될 수 있는 변형이라는 점에서 채택되었습니다(Arun의 답변 참조).

Facebook이 Flux를 도입했을 때, MVVM/MVP/MV*의 문제와 비교했지만, MVC라는 용어를 헷갈리게 사용했습니다.

이 비디오를 시청하는 순수한 MVC 개발자들에게는 MVC에 관한 Facebook의 문제는 의미가 없으며, Facebook의 Flux에 대한 설명은 그들이 설명한 MVVM 시스템보다 MVC에 가까웠다.

가장 중요한 문제는 MVC를 "잘못하고"하고 있었다는 것입니다.그 후 수정했지만, 리브랜딩하기로 하고 데이터, 뷰 및 이벤트 처리 방식을 개발했다고 밝혔습니다.

유튜브 댓글

프로그래머들이 MVC와 이벤트 디스패처를 제대로 사용할 줄 몰라서 플럭스를 만든 것 같아요.

유튜브 댓글

언급URL : https://stackoverflow.com/questions/33447710/mvc-vs-flux-bidirectional-vs-unidirectional