Coderifleman's blog

frontend development stories.

「Architecture」가 태그 돼 있는 글

  • 플럭스 아키텍처를 이용해 애플리케이션을 개발할 때 가장 먼저 스토어를 설계한다. 그 이유는 스토어가 무엇보다 중요한 데이터를 관리하는 객체라고 해석하기 때문이다.

    스토어는 모델이나 엔티티 등의 데이터를 관리하기 위한 공간이 아니다. 그저 표현을 위한 상태를 관리하는 객체일 뿐이다. 예를 들어 데이터를 필터링하기 위한 기준값이 있다고 하자. 이 값이 스토어에 존재한다고 해서 실제 필터링에 사용되지 않는다. 스토어에 존재하는 이유는 이 값을 어딘가에 표현해야 하기 때문이다.

    표현 계층은 표현을 위한 상태가 필요하다. 그리고 애플리케이션 비즈니스는 필연적으로 도메인 데이터가 필요하다. 만약 두 가지의 책임을 스토어가 갖게 된다면 애플리케이션 내에서 무엇보다 중요한 거대한 객체가 탄생하게 된다.

    스토어의 의존 관계
    <그림 1. 스토어의 의존 관계>

    첫 번째 다이어그램을 보자. 스토어에서 표현을 위한 상태와 도메인 데이터를 모두 관리하고 있다. 이 경우 표현 계층과 애플리케이션 비즈니스 계층 모두 스토어를 의존한다. 애플리케이션 비즈니스는 도메인 데이터에 접근할 수 있어야 하므로 스토어에 겟터(Getter) 메서드도 작성해야 한다.

    반면 두 번째 다이어그램에서는 데이터의 관리 책임을 분리했다. 자연스럽게 의존 관계는 좌측에서 우측으로 이뤄진다. 스토어에서 겟터를 제공할 필요도 없다. 데이터를 관리하는 계층에서 적절한 수단을 제공하면 된다. 스토어는 상대적으로 단순하고 각 계층을 테스트하기도 쉽다.

    플럭스 아키텍처 의존 관계
    <그림 2. 플럭스 아키텍처 의존 관계>

    필자는 스토어를 표현 계층의 한 요소로 해석한다. 스토어에서 도메인 데이터를 분리해야만 클린 아키텍처에서 말하는 의존 규칙을 지킬 수 있다.

    플럭스 아키텍처를 이용해 애플리케이션을 설계하더라도 모델 계층은 언제나 필요하다. 즉, 애플리케이션을 개발할 때 가장 먼저 시작해야 할 지점은 스토어가 아니라 바로 모델이다.

  • 읽기전에...

    이 문서는 일본어 「クリーンアーキテクチャ(The Clean Architecture翻訳)」을 중역한 글입니다. 원글은 「The Clean Architecture」로 번역 시 참고했습니다. 오역 감수는 프런트엔드 개발자 이두용님께서 수고해주셨습니다.

    로버트 C. 마틴(Robert Martin, a.k.a 엉클 아저씨)이 공개한 「The Clean Architecture」를 번역한 글입니다. 관점이 비슷한 「Hexagonal Architecture(일본어)」도 번역했으니 참고해주세요.

    해당 글을 번역하겠다고 「8th Light, inc」에 이야기했으며 현재까지는 별다른 제재가 없었습니다.

    The Clean Architecture의 다이어그램
    <그림. The Clean Architecture의 다이어그램>

    지난 몇 년 동안 우리는 시스템 아키텍처에 대한 실로 다양한 아이디어를 봐왔다. 예를들어 다음과 같은 것이 포함된다.

    위 아키텍처의 세세한 부분은 모두 다르지만 매우 비슷하기도 하다. 이들은 모두 같은 목적을 갖고 있는데 바로 관심사의 분리다. 소프트웨어를 계층으로 나눔으로써 관심사를 분리한다. 그리고 모두 비즈니스 규칙을 위한 최소 하나 이상의 계층과 인터페이스를 위한 또 다른 계층을 두고 있다.

    위 아키텍처 모두는 다음과 같은 시스템을 생성한다.

    1. 프레임워크 독립적, 이들 아키텍처는 소프트웨어 라이브러리 존재 여부에 의존하지 않는다. 이는 시스템을 프레임워크의 한정된 제약에 억지로 집어넣는 대신 도구로써 사용하는 것을 가능하게 한다.
    2. 테스트 용이함, 비즈니스 규칙은 UI, 데이터베이스, 웹 서버, 기타 외부 요인없이 테스트 가능하다.
    3. UI 독립적, 시스템의 나머지 부분을 변경할 필요 없이 UI를 쉽게 변경할 수 있다. 예를들면 웹 UI는 비즈니스 규칙 변경 없이 콘솔 UI와 치환된다.
    4. 데이터베이스 독립적, 오라클 또는 SQL Server를 몽고, 빅테이블, 카우치 DB 등으로 바꿀 수 있다. 비즈니스 규칙은 데이터베이스에 얽매이지 않는다.
    5. 외부 기능 독립적, 실제로 비즈니스 규칙은 외부 세계에 대해 아무것도 모른다.

    이 문서의 말머리에 소개한 그림은 이러한 아키텍처를 단일 개념으로 통합하고자 하는 시도다.

    의존 규칙

    이들 동심원은 소프트웨어의 각기 다른 영역을 나타내고 있다. 대개, 바깥쪽으로 향할수록 고수준의 소프트웨어가 된다. 바깥쪽의 원은 메커니즘(Mechanism)이고 안쪽의 원은 정책(Policy)이다.

    이 아키텍처를 기능하게 하는 중요한 규칙이 바로 의존 규칙이다. 이 규칙에 의해서 소스 코드는 안쪽을 향해서만 의존할 수 있다. 안쪽의 원은 바깥쪽의 원에 대해 전혀 알지 못한다. 특히, 바깥쪽의 원에서 선언된 어떠한 이름을 안쪽 원에서 참조해서는 안된다. 이는 함수, 클래스, 변수 등 이름이 붙은 소프트웨어의 엔티티 모든 것에 해당한다.

    마찬가지로 바깥쪽의 원에서 사용하고 있는 데이터 포맷을 안쪽의 원에서 사용하지 않아야 한다. 특히 그러한 포맷이 바깥쪽 원에서 프레임워크에 의해 생성되고 있다면 바깥쪽 원의 어떠한 것도 안쪽의 원에 영향을 줘선 안된다.

    엔티티

    엔티티는 대규모 프로젝트 레벨의 비즈니스 규칙을 캡슐화 한다. 엔티티는 메서드를 갖는 객체 일 수도 있지만 데이터 구조와 함수의 집합일 수도 있다. 엔티티가 대규모 프로젝트 내의 다양한 애플리케이션에서 사용된다고 하더라도 문제될 것은 없다.

    대규모 프로젝트가 아닌 단지 하나의 애플리케이션을 작성할 뿐이라면 엔티티는 그 애플리케이션의 비즈니스 객체가 된다. 엔티티는 가장 일반적이면서 고수준의 규칙을 캡슐화한다. 그리고 바깥쪽에서 무엇이 변경되더라도 바뀌지 않는다. 예를들어 엔티티 객체는 페이지 내비게이션의 변경이나 보안 사항으로 부터 영향을 받지 않을 것을 기대할 수 있다. 애플리케이션의 동작에 관한 변경이 엔티티 계층에 영향을 주어선 안된다.

    유스케이스

    이 계층의 소프트웨어는 애플리케이션 고유 비즈니스 규칙을 포함하며 시스템의 모든 유스케이스를 캡슐화하고 구현한다. 이들 유스케이스는 엔티티로 부터의 혹은 엔티티에서의 데이터 흐름을 조합한다. 그리고 엔티티 즉, 프로젝트 레벨의 비즈니스 규칙을 사용해 유스케이스의 목적을 달성하도록 지휘한다.

    이 계층의 변경이 엔티티에 영향을 주지 않을 것을 기대하며 데이터베이스, UI 또는 공통의 프레임워크의 변경으로부터 영향 받지 않을 것도 기대한다. 이 계층은 그러한 관심에서 격리된다.

    하지만, 애플리케이션의 조작에 대한 변경은 유스케이스에 영향이 있고 따라서 이 계층의 소프트웨어에 영향이 있을 것을 기대한다. 유스케이스의 상세가 바뀐다면 이 계층의 코드는 확실히 영향을 받는다.

    인터페이스 어댑터

    이 계층의 소프트웨어는 어댑터의 집합이다. 이는 유스케이스와 엔티티에 있어 용이한 형식으로부터 데이터베이스나 웹 등 외부의 기능에 용이한 형식으로 데이터를 변환한다. 예를들어 이 레이어는 GUI의 MVC 아키텍처를 완전히 내포한다. 프리젠터, 뷰, 컨트롤러는 모두 여기에 속한다. 모델은 컨트롤러에서 유스케이스로 전달되고 이어 유스케이스에서 프리젠터나 뷰로 되돌아가는 그저 단순한 데이터 구조일 가능성이 높다.

    마찬가지로 이 계층에서 데이터는, 엔티티나 유스케이스에 용이한 형에서, 사용하고 있는 프레임워크에 용이한 형으로 변환된다. 예를들어 데이터베이스를 들 수 있다. 이 계층에 해당하는 원보다 안쪽에 존재하는 코드는 데이터베이스에 관해 아는 것이 없어야 한다. 만약 데이터베이스가 SQL 데이터베이스라면 어떤 SQL이든 이 계층에 제한돼야 하며 특히, 이 계층 내의 데이터베이스와 관련 있는 부분에 제한돼야 된다.

    또, 이 계층에는 외부의 어떠한(외부 서비스) 형식에서 유스케이스와 엔티티에서 사용될 수 있는 내부 형식으로 데이터를 변환하기 위해 필요한 기타 모든 어댑터도 둘 수 있다.

    프레임워크와 드라이버

    가장 바깥쪽의 계층은 데이터베이스나 웹 프레임워크 등 일반적으로 프레임워크나 도구로 구성된다. 대개, 이 계층에는 안쪽의 원과 통신할 연결 코드 이외에는 별다른 코드를 작성하지 않는다.

    이 계층에는 상세한 정보가 무엇이든 여기에 둔다. 웹은 상세하다. 그리고 데이터베이스도 상세하다. 이러한 것으로 인해 악영향을 주지 않도록 밖에 유지한다.

    4개의 원이 아니면 안되는가

    아니다. 이 원은 컨셉을 전하기 위한 수단이다. 이 4가지 이외에도 무엇인가 필요할 가능성이 있다. 정확히 4가지가 아니면 안된다는 규칙은 없다. 하지만 의존 규칙은 항상 적용된다. 소스 코드의 의존성은 항상 안쪽으로 향해야 한다. 안쪽으로 향해감에 따라 추상화 수준은 올라간다. 가장 바깥쪽의 원은 저수준의 구체적인 상세 정보를 담는다. 안쪽으로 이동해가면서 소프트웨어는 추상화 되고 고수준의 정책을 캡슐화한다. 가장 안쪽에 있는 원은 무엇보다 일반성이 있다.

    교차경계

    위 다이어그램의 오른쪽 아래의 그림은 어떤식으로 원의 경계가 교차하는지 보여주는 예다. 이것은 컨트롤러와 프리젠터가 다음 계층인 유스케이스와 어떻게 대화하는지 보여준다. 제어의 흐름에 주의하길 바란다. 컨트롤러에서 시작해 유스케이스를 거쳐 프리젠터에서 실행됨을 알 수 있다. 소스 코드의 의존성에도 주의한다. 모두 안쪽의 유스케이스를 향하고 있다.

    우리는 이 분명한 모순을 의존 관계 역전의 원칙(Dependency Inversion Principle)으로 해결하는 경우가 많다. 예를들어 Java와 같은 언어에서는 인터페이스와 상속 관계를 조합해 소스 코드의 의존성이 경계를 걸치고 있는 오른쪽 지점에서 제어 흐름이 반대하도록 한다.

    다시 예를들어 유스케이스가 프리젠터를 호출할 필요가 있는 경우를 생각해보자. 하지만 이때의 호출은 직접 이뤄질 수 없다. 왜냐하면 “의존성 규칙 : 바깥쪽의 이름을 안쪽에서 언급할 수 없다”를 위반하기 때문이다. 때문에 유스케이스에는 안쪽 원에 있는 인터페이스(Use Case Output Port라고 적혀있는)를 호출한다. 그리고 원 바깥쪽의 프리젠터는 이 인터페이스를 구현한다.

    이와 똑같은 테크닉이 아키텍처의 경계가 교차되는 곳에서 사용된다. 동적인 다형성의 이점을 이용해 소스 코드의 의존성이 제어 흐름의 반대가 되도록 한다. 이렇게 하면 제어의 흐름이 어떤 방향으로 진행되든지 상관없이 의존성 규칙을 지킬 수 있다.

    어떤 데이터가 경계를 교차하는가

    대개, 경계를 넘나드는 데이터는 단순한 구조의 데이터다. 기본적인 구조체나 단순한 데이터 전송 객체(Data Transter Object)를 취향에 맞게 사용할 수 있다. 혹은 데이터는 단순히 함수의 인수라 해도 좋다. 또는, 그것을 해시맵으로 해도 좋고 객체로 구성해도 좋다. 중요한 것은 격리된 단순한 구조의 데이터가 경계를 넘어간다는 점이다. 우리는 꾀를 부려 엔티티나 데이터베이스의 행을 전달하지 않는다. 데이터 구조가 의존성 규칙을 위반하는 모든 종류의 원인을 갖지 않길 바란다.

    예를 들어 여러 데이터베이스 프레임워크는 쿼리에 응답하여 편리한 데이터 포맷을 반환한다. 이것을 행 구조(RowStructure)라고 부르자. 이 행 구조를, 경계를 넘어 안쪽으로 전달하지 않기를 원한다. 이는 의존성 규칙을 위반한다. 왜냐하면 바깥쪽 원에 관한 무언가를 안쪽의 원이 알도록 강제하기 때문이다.

    때문에 경계를 넘어 데이터를 전달할 때엔 항상 안쪽의 원이 다루기 쉬운 데이터 형식이어야 한다.

    결론

    이런 간단한 규칙을 따르는 것은 어렵지 않다. 그리고 머리가 아프지 않도록 도와 줄 것이다. 소프트웨어를 계층으로 나누고 의존성 규칙을 따름으로써 본질적으로 테스트하기 쉬운 시스템을 만들 수 있고 의존성 규칙이 가져오는 이점도 얻을 수 있다. 시스템의 외부 부품(데이터베이스나 웹 프레임워크 등)이 낡았다면 그러한 부분도 최소한의 노력으로 바꿀 수 있다.

  • 읽기전에...

    이 문서는 InfoQ의 「Facebook: MVC Does Not Scale, Use Flux Instead(일본어, 영어)」를 번역한 글입니다. 주로 일본어 문서를 번역했으며 영어 문서는 참고 자료로써 사용했습니다.

    이 문서는 개발자 커뮤니티와 Jing Chen(페이스북)의 반응을 바탕으로 업데이트하고 있다.(아래 Update 절 참고)

    페이스북은, MVC 패턴으로는 자신들이 원하는 명세를 수용할 수 없다고 결론을 내리고 대신 또 다른 패턴인 Flux 사용을 결정했다.

    지난 F8의 「Hacker Way: Rethinking Web App Development at Facebook」 세션에서 페이스북의 기술 매니저인 Tom Occhino는 일정 수준 이상의(sufficiently) 코드 베이스와 대규모 개발 조직에 관해 설명하고 거듭 「MVC는 정말 눈 깜짝할 사이에 복잡해진다」 라고 말하며 MVC는 큰 시스템에 어울리지 않는다고 결론지었다. 어떤 새로운 기능을 추가하려고 할 때마다 시스템의 복잡도는 기하급수적(지수, exponential)으로 증가하며 「깨지기 쉽고 예측 불가능한 코드」가 된다, 이것은 거대한 코드 베이스에 참여한 개발자에게 「이미 존재하는 기능에 문제를 발생시킬까 두려워 코드를 수정하지 못하는 새로운 심각한 문제」를 일으킨다고 이어서 말했다. 그 결과 페이스북은 MVC와 결별하게 된 것이다.

    이 문제를 해결하기 위해서는 「좀 더 예측 가능한 형태로 코드를 구조화하는 것」이 필요하며 이것은 Flux와 React를 이용해서 달성할 수 있다고 한다. Flux는 애플리케이션 내의 데이터 흐름을 단방향(single directional data flow)으로 흐를 수 있도록 도와주는 시스템 아키텍처다. React는 예측 가능하며 선언적(또는 서술적)으로 웹 애플리케이션을 구축하기 위한 자바스크립트 프레임워크이며 페이스북의 웹 애플리케이션 개발을 더욱 빠르게 할 수 있도록 한다고 Tom Occhino는 말했다.

    Jing Chen씨는 이어서 MVC는 소규모 애플리케이션에는 적합하지만 아래 이미지처럼 Model이나 Model과 관련한 View가 대량으로 시스템에 추가되면 복잡도가 폭발적으로 증가한다고 말했다.

    MVC의 데이터 흐름
    <그림 1. MVC의 데이터 흐름>

    이러한 애플리케이션은 Model과 View 사이의 데이터를 양방향(bidirectional data flow)으로 흐르게 할 가능성이 있고, 따라서 이해하고 디버깅하기 어렵다고 말하면서 대신 아래 Flux와 같은 설계를 제안했다.

    Flux의 데이터 흐름
    <그림 2. Flux의 데이터 흐름>

    그림 2의 Store는 애플리케이션의 모든 데이터를 포함한다. Dispatcher는 MVC의 Controller를 대체하며 어떠한 Action이 발생(trigger)했을 때 어떻게 Store를 갱신할지를 결정한다. Store가 변경될 때에는 View도 동시에 갱신된다. 또, 선택적으로 Dispatcher가 처리할 Action을 발생시킬 수도 있다. 이처럼 시스템의 컴포넌트 간 데이터 흐름은 단방향으로 유지됨을 알 수 있다. 데이터는 단방향으로만 흐르고 각각의 Store와 View는 서로 직접적인 영향을 주지 않기 때문에 여러 개의 Store나 View를 갖는 시스템도, 하나의 Store나 View 갖는 시스템과 같다고 볼 수 있다.

    페이스북 깃-허브의 Flux Overview 페이지에 Flux나 Dispatcher 그리고 Store에 관해 자세히 작성돼 있다.

    Dispatcher와 Store

    Dispatcher는 Flux 아키텍처의 모든 데이터 흐름을 관리하는 중앙 허브다. 이는 본질적으로 Store 내에서 콜백을 등록할 때 사용하는 장소다. 각 Store는 Dispatcher에 등록할 콜백을 제공한다. 이 Dispatcher가 발생시킨 Action에 응답할 때 애플리케이션 내의 모든 Store는 Dispatcher에 등록한 콜백을 통해 Action에 의해 생긴 데이터를 송신한다.

    등록된 콜백을 정해진 순서로 실행하여 Store 간의 의존 관계를 관리할 수 있으므로 애플리케이션이 커질수록 더욱 없어선 안 될 존재가 된다. 선언에 따라 Store는 다른 Store의 갱신이 완료될 때까지 기다린 다음 자기 자신을 갱신할 수 있다.

    Store는 애플리케이션의 상태나 논리를 포함한다. Store의 역할은 전통적인 MVC의 Model 역할과 조금 비슷하다. 하지만 다수의 객체의 상태를 관리하는 MVC와 달리 단일 객체 인스턴스(싱글-톤)로 관리한다. 또, Backbone 프레임워크의 컬렉션과도 같지 않다. ORM 형식의 객체를 집합으로 관리하기보다 조금 더 단순하게 애플리케이션 내의 한 특정 도메인에 관한 애플리케이션의 상태를 관리한다.

    중요한 것은 데이터 계층에서 다른 Action이 발생하기 전에 자신과 관계를 맺고 있는 View의 갱신을 끝내는 것이라고 Jing Chen씨는 말했다. Dispatcher는 이전 Action의 처리를 완료하지 않은 상태라면 다음 Action의 처리를 거부할 수 있다. 이 설계 방식은 다른 View도 함께 갱신할 때 발생할 수 있는 부작용을 가지고 있는 Action에 대응할 때 유용하며 코드를 좀 더 명확하게 이해할 수 있고 새로운 개발자도 디버깅을 간단하게 할 수 있도록 한다고 했다. Flux는 페이스북 채팅의 버그(가짜 신규 메시지 통지를 발생시키는 버그)를 수정하는 역할로 사용됐다.

    Flux TodoMVC 튜토리얼소스 코드는 깃-허브에 공개돼 있다.

    물론 페이스북이 그들이 옳다고 생각하는 설계 방식을 따르는 것은 그들의 자유지만, 여전히 의문은 남아있다. 과연 정말 MVC는 확장에 용이하지 않을까? 이미 주변의 많은 웹사이트는 성장하고 확장되고 있다.

    Update. 이 기사를 공개한 뒤, MVC에 관한 페이스북의 결정에 관해 많은 개발자가 Reddit을 통해 의견을 보냈다. 여기에서 댓글 몇 개를 소개하겠다. 애초에 페이스북이 MVC를 오용했다고 생각하는 사람도 있지만, 페이스북이 올바른 결정을 했다고 생각하는 사람도 있다.

    giveupitscrazy :

    이건 전혀 의미가 없다. 먼저 그들의 MVC 구성에는 두드러지는 결함이 있다. 그들은 컨트롤러가 상호 작용하고 있는 Model에 따라서 혹은 논리적인 이유로 누구나 분할이 필요하다고 느껴지는 때조차 여러 Model을 조작하는데 단 한 개의 컨트롤러를 사용하고 있다. 물론 그들이 묘사하고 있는 MVC는 동작하지 않겠지만 그래도 그것은 진짜 MVC가 아니다. 만약 그들의 Flux의 다이어그램과 실제 MVC의 다이어그램을 비교한다면 웹 애플리케이션에 있어 MVC가 본질적으로 문제 될 것이 없다는 것을 분명히 알 수 있다.

    balefrost :

    그렇다. 그들의 Flux 다이어그램은 모두가 알고 있는 MVC의 다이어그램과 매우 닮아있다. 그들은 실용적인 MVC를 재발명(re-invented)했을 것이다. 그리고 그것에 새로운 이름을 붙이기로 결정한 것이다. 아하!

    hackinthebochs :

    이 아키텍처는 이벤트 주도 방식으로 기존 MVC를 조금 변경한 것이다. 「Store」는 자기 자신(그리고 아마도 호출 순서의 의존성)을 Dispatcher에 등록하고 그 Dispatcher는 Action을 처리하여 올바른 호출 순서가 달성되도록 보증한다. 이것은 올바른 호출 순서를 보증해야 하는 부담을 컨트롤러에서 Dispatcher와 Store로 분리한 것이다. 이것은 동작을 수정하는 데 필요한 지식을 줄여준다.

    runvnc :

    이 아키텍처를 아주 깊게 이해했다고 아직 말할 수는 없지만, 어느 정도는 이해했다고 생각하고 있고 전반적인 아이디어에 찬성한다.

    Reddit 유저 jingc09는 댓글 내용을 보아하니 Jing Chen으로 보인다. 아래에 몇 가지 답변하고 있다.

    jingc09 :

    확실히 저것(그림 1)은 까다로운 슬라이드였다(하나의 컨트롤러가 다수의 Model이나 View와 결합하고 있고, 데이터는 양방향으로 흐르고 있다). 이 논쟁의 원인의 일부는 MVC가 엄밀히 무엇인지에 대해 충분히 일치된 의견 없이 많은 사람이 각각의 의견을 가지고 있기 때문이다. 본래 우리가 논해야 할 주제는 양방향 데이터 흐름에 대해서다. 그것은 한쪽의 데이터 변경이 또 다른 쪽에 영향을 줄 수 있고(loop back), 한편 연쇄적인 효과도 가지고 있다.

    그녀의 말을 명확하게 이해하기 위해서 「Flux의 Dispatcher는 MVC 컨트롤러가 아니다」라는 글을 보는게 좋다.

    한가지 내가 밝히고 싶은 것은 Dispatcher가 Controller와 같은 역할을 담당하는 것은 아니라는 것이다. Dispatcher는 비즈니스 로직을 가지고 있지 않고 우리는 Dispatcher 코드를 복수의 애플리케이션에서 재사용하고 있다. 그것은 단지 이벤트에 대응하는 구독자(대개 Store)를 등록하기 위한 중앙 허브에 불과하다. 그러나 단방향 데이터 흐름을 가능케 하는 장소이기 때문에 Flux 아키텍쳐에 있어서 중요한 요소다.

    Wikipedia의 MVC 컨트롤러에 관한 설명 글에는 다음과 같이 작성돼 있다.

    컨트롤러는 Model의 상태를 갱신하기 위해(예를 들어 문서 편집 등) 명령을 할 수 있다. 또 그것은 Model에 관계한 View의 출력을 변경하기 위해(여를 들어 문서의 스크롤) View에게도 명령을 할 수 있다.

    Jing Chen은 말했다.

    Dispatcher에서는 이러한 작업을 할 수 없다. 그 명령은 다른 어딘가(View나 서버의 응답, 라이브 갱신 등)에서 출발하여 Dispatcher에 전송해야 한다. Todomvc-flux의 Dispatcher.js(아마 그 코드는 Actions로 옮겨진 것 같다)를 보면 이러한 사실을 이해할 수 있을 것이다.

    Reddit의 댓글을 살펴보면 MVC가 어떤 것이며 어떤 방법으로 구현 해야 하는지 대해 잠시 혼란이 있어 보인다.

    Facebook의 MVC에 관한 결정에 관해 우리는 아래와 같은 두 가지 관점을 가지고 있다.

    1) 첫 번째 슬라이드의 다이어그램은 너무 많은 Model과 View가 관계를 맺는 억지스러운 예이기 때문에 독자에게 이런 경우가 실존하는 것인지 의문점을 안긴다. 페이스북이 Flux로 해결한 문제는 고작 3개의 View를 가진 채팅 애플리케이션이었다.

    2) 그들의 MVC 예에서는 왜 View가 데이터 흐름을 생성해 양방향 데이터 흐름을 만들어 낼까? 또 왜 이 Flux의 다이어그램에서는 View가 Action을 발생시키는 것일까? View는 그냥 View 일뿐이므로 View는 아무것도 발생시키지 않아야 할 것이다. 페이스북은 MVC를 오용하고 있는 것은 아닐까?