디자인 패턴을 읽었으며 제작자가 옵서버 패턴이 멋지다고 동의하는 반면, 디자인 할 때는 모두 MVC를 말합니다.모델 -> 옵저버 ->보기 -> 컨트롤러 -> 모델 ->
저는 약간 혼란 스럽 습니다만, MVC 다이어그램은 순환 적이 지 않습니다. 코드 흐름이 토폴로지를 닫지 않았습니까? 왜이 패턴을 말하는 사람이 아무도 :
model -> observer -> view -> listener -> model -> ..
보기가 컨트롤러가 필요하다면 모델은 관찰자가 필요합니까? Object.observe()가 다음 JavaScript 버전과 함께 제공되면 과 같은 패턴이 잘못되었습니다? 
뷰와 컨트롤러는 모두 옵저버입니다.
모델의 이벤트보기/관찰자입니다. 컨트롤러는 뷰의 이벤트 관찰자입니다. 컨트롤러는 모델에서 명령을 실행하여 뷰를 관찰하여 해당 상태를 적절하게 변경하는 이벤트를 전파하는 결과를 가져옵니다.
이 문제는 모델의 변경 사항에 UI가 응답하고 UI를 통해 사용자의 입력에 모델이 응답하게하는 문제입니다. 인간 시각의 취약성 이외에 세 번째 구성 요소가 포함될 큰 이유가 없습니다. 이벤트 구동 시스템보다 명령 및 제어 시스템을 구상하는 것이 훨씬 쉽습니다. 그러나 놀라 울 정도로 후자는 종종 구현하기가 더 쉽습니다.
제안 된 디자인에 대한 하나의 문제는 관심사의 분리입니다. MVC (메시지/이벤트가 제대로 수행되면)는 각 구성 요소가 자체 및 자체 관심사에 대해서만 알고 있습니다. Observer 구성 요소가 제안하는 모델에서 뷰를 조율하는 방법을 알아야합니다.
물론 컨트롤러가 모델 변경을 조정한다고 생각하고 있습니다. 그렇다면 관계의 맨 끝에 동등한 구성 요소가없는 이유는 무엇입니까?
사실 우리는 '컨트롤러'공간에 뭔가를 구현하지만 일반적으로보기에서 메시지/이벤트/명령을 모델로 전달하는 '인프라'만 있습니다. 그에 따라 적절하게 응답합니다. 컨트롤러가 간단한 라우터로 변경되었습니다. 오케스트레이션 구성 요소에 대한 필요성은 DDD 및 집합 루트 패턴에 대한 더 나은 이해와 이벤트 소싱의 가능성으로 인해 현대 디자인에서 감소되었습니다.
마지막으로 언급 한 패턴은 Gang of Four에서 실제로 실용적이며 상대적으로 일반적이라고 기록되어 있습니다. 당시에는 모바일 또는 웹 응용 프로그램이 없었으며 가장 큰 시스템 중 하나는 김프였습니다. 우리의 기술이 성숙되고 우리의 앱이 여러 채널을 통해 전달되므로이 공간에서 개발 패턴을 가질 수 있습니다. 몇 년 전에 우리는 MVC2에 대해 논의하고 있었고 MVVC와 MMVC와 같은 이상한 곳으로 이동했습니다. 이제는 CQRS, 이벤트 소싱 및 DDD를 통해 오케스트레이션 방식이 한계점을 드러내고 이벤트 중심 시스템이 전면에 나타나기 시작하면서 MV에 대해 이야기하기 시작했습니다.
내가 이해하는 한,보기는 모델을 제어 할 수 없으므로보기가 컨트롤러를 제어해야합니까? –
MVC에서 뷰는 모델을 직접 변경할 수 없습니다. 컨트롤러가하는 일입니다. 컨트롤러는 모델의 변경 사항을 조정하여 뷰의 이벤트에 응답합니다. –
오, 글쎄, 나는 '시합'CQRS, 이벤트 소싱, DDD '를 읽어야합니다. 나는 당신의 대답을 미리 표시 할 것이고, 희망을 갖고 대답은 거기에있다. –
작은 메모 -'Object.observe()'는 더 이상 사용되지 않으며'Proxy()'는 ES2015 표준의 일부로 대체됩니다. https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Proxy – Brian