我正在阅读设计模式，虽然作者同意观察者模式很酷，但在设计方面，每个人都在谈论 MVC。
我有点困惑，MVC图不是圆形的，代码流有封闭的拓扑不是很自然吗？为什么没有人谈论这种模式：
model -> observer -> view -> listener -> model -> ..
如果视图需要控制器，那么模型需要观察者，不是吗？随着 Object.observe() 与下一个 JavaScript 版本一起出现，这种模式有什么问题？
【问题讨论】：
Object.observe() 已被弃用，Proxy() 我相信是它的替代品，并且是 ES2015 标准的一部分 developer.mozilla.org/en/docs/Web/JavaScript/Reference/…
标签： javascript design-patterns model-view-controller
View 和 Controller 都是观察者。
视图/是/模型上事件的观察者。控制器/是/视图中事件的观察者。控制器在模型上触发命令，这会导致模型发生变化，从而传播由视图观察到的事件，从而适当地改变其状态。
这试图解决的问题是让 UI 响应模型中的更改，并让模型通过 UI 响应用户的输入。除了人类视觉的脆弱性之外，没有很好的理由让第三个组件参与其中——想象一个命令和控制系统比一个事件驱动系统容易得多，尽管令人惊讶的是后者通常更容易实现。
您提出的设计的一个问题是关注点分离。使用 MVC（如果处理得当，使用消息/事件），每个组件只知道自己和自己的关注点。对于您提出的模型，Observer 组件必须知道如何编排视图，这是视图最好自己完成的事情。
当然，您认为控制器会协调对模型的更改，那么为什么我们不在关系的另一端有一个等效组件呢？
事实上，虽然我们通常会在“控制器”空间中实现某些东西，但通常只是“基础架构”将消息/事件/命令从视图传递到模型，模型会做出相应的响应——也就是说，通常是控制器演变成一个简单的路由器。由于我们对 DDD 和聚合根模式的更好理解，当然还有事件溯源的可能性，现代设计中对编排组件的需求已经减少。
最后，您所指的模式最初是由四人帮记录的，在实践中存在并且相对普遍。当时没有移动或网络应用程序，他们认为最大的系统之一是 gimp。由于我们的技术已经成熟，我们的应用程序通过多种渠道交付，因此该领域的开发模式也有所变化。几年前我们在讨论 MVC2，然后我们转向像 MVVC 和 MMVC 这样的怪事。现在，随着 CQRS、事件溯源和 DDD 的出现，我们开始讨论 MV，因为编排方法已经开始显示其局限性，并且事件驱动系统脱颖而出。
【讨论】：