javascript - 模型 -> 观察者 -> View -> Controller -> 模型 ->

Question

我正在阅读有关设计模式的文章，虽然作者们都认为观察者模式很酷，但在设计方面，每个人都在谈论 MVC。

我有点困惑，MVC 图不是循环的，代码流具有闭合拓扑不是很自然吗？为什么没有人谈论这种模式:

model -> observer -> view -> listener -> model -> ..

如果 View 需要 Controller ，那么模型就需要观察者，不是吗？随着下一个 JavaScript 版本推出 Object.observe()，这种模式有什么问题？

Answer 1

View 和 Controller 都是观察者。

View 是模型上事件的观察者。 Controller 是 View 中事件的观察者。 Controller 在模型上触发命令，这会导致模型发生变化，从而传播由 View 观察到的事件，从而适本地更改其状态。

此尝试解决的问题是让 UI 响应模型中的更改，并让模型通过 UI 响应用户的输入。除了人类视觉的脆弱性之外，没有什么充分理由让第三个组件参与其中——想象一个命令和控制系统比事件驱动系统要容易得多，尽管令人惊讶的是后者通常更容易实现。

您提出的设计的一个问题是关注点分离。使用 MVC(如果正确完成，使用消息/事件)每个组件只知道它自己和它自己的关注点。对于该模型，您建议观察者组件必须知道如何编排 View ，而 View 更适合自己完成这些工作。

当然，您认为 Controller 会协调对模型的更改，那么为什么我们不在关系的另一端拥有等效的组件呢？

事实上，虽然我们通常在“ Controller ”空间中实现一些东西，但它通常只是将消息/事件/命令从 View 传递到模型的“基础设施”，模型会做出相应的响应——也就是说，通常是 Controller 退化为一个简单的路由器。由于我们对 DDD 和聚合根模式以及事件溯源的可能性有了更好的理解，现代设计中对编排组件的需求已经减少。

最后，您所指的模式最初由四人帮记录为在实践中存在且相对常见。当时还没有移动或网络应用程序，他们认为最大的系统之一是 gimp。随着我们的技术已经成熟，并且我们的应用程序通过多种 channel 交付，因此该领域的开发模式也已形成。几年前我们讨论了 MVC2，然后我们转向了 MVVC 和 MMVC 等奇怪的东西。现在，随着 CQRS、事件溯源和 DDD，我们开始谈论 MV，因为编排方法已经开始显示出其局限性，并且事件驱动系统脱颖而出。