Cocoa MVC实际上不是MVP模式吗？

Question

再一次，一个与MVC相关的问题。几天前我开始阅读苹果的Cocoa基础指南，在其中苹果解释了他们对MVC的实现。

在MVC作为复合设计模式（link）章节中，他们比较了两个MVC版本：

• 老的/传统的SmallTalk版本：

• 当前Apple定义的版本：

他们对这个当前模型的描述如下：

这个复合设计模式中的控制器对象包括调停者模式和策略模式；它在模型和视图对象之间双向地调节数据流。 模型状态的变化通过应用程序的控制器对象向视图对象通信。

传统模式看起来像MVC，没有问题。但是他们当前模式的名称让我感到困惑。在我的认知中，这可能被视为普通的MVP，因为控制器似乎总是在视图和模型之间进行调解。

我完全错了吗？我是否误解了MVC或MVP？还是苹果只是使用了错误的名称来命名此模式？更重要的是，为什么当前模式被称为MVC？

- Thomas Smith

---

这有点取决于情况。如果你的“视图”只是愚蠢的模板，而模型只是活动记录实例的集合，那么你所拥有的甚至不是MVP。它只是Rails的克隆。 - tereško

Answer 1

你没说错，但苹果文档的作者也没有错。

MVC 的历史现在已经变得又长又复杂了——其中很多系统主张三分法的分离，实际上混淆了控制器与模型或将控制器与视图混合在一起。从早期的 Smalltalk 实现开始，就清楚地表明将模型信息与视图分离开来是一件非常好的事情，而且这样做相当容易。

另一方面，清晰地分离控制器和视图的职责则要困难得多。许多视图希望被重用，例如按钮或文本字段。它们的控制器的可重用部分也想被重用。但是你不能推送一个文本字段或者粗体显示一个按钮；许多按钮行为与视图紧密相关。同时，很难确定业务规则应该属于模型还是控制器。

此外，这份（非常好的）苹果文档试图捕捉一种哲学设计思想，而不是描述唯一正确的方法。许多 Cocoa 控制器子系统看起来很像传统的 MVC。传统 Cocoa 忽略了控制器，因此这份文档本质上是在主张给它们一个作为视图和模型之间中介的位置。

许多 Cocoa 实现者更喜欢薄控制器，基本上作为外观工作，以解耦视图和模型。

- Mark Bernstein

---

好的回答。甚至Cocoa的好部分也跨越了这些界限。出于性能原因，NSImage封装了控制器行为，如故障和缓存，并且NSImageView可能会请求调整大小的表示形式而不咨询中介控制器。此外，拥有针对特定模型类构建的视图的NSImageView是完全合理的。此外，Apple文档提到了Cocoa绑定，但暗示它们是视图和模型之间未经调解的连接。我通常只将绑定本身视为中介控制器，特别是考虑到消息流。 - paulmelnikow

很好的回答。我看到这更多地展示了一般良好实践，而不是定义一种精确且总是正确的设计方式。MVC并没有固定在一个定义上，相反它展示了一种灵活/抽象的应用程序开发思想。感谢您的时间。 - Thomas Smith

Answer 2

由于MVP是MVC的子集，因此在MVC系统中找到它并不奇怪。是的，第二个图示说明了MVP模式。

苹果称其为调解控制器，我认为这只是MVP的另一个名称。

老实说，我不确定“MVP”这个术语是否应该流行起来。它暗示了它是一种完全不同的模式，“Presenter”似乎专注于UI，而有时它只是模型和控制器之间的关系。“调解控制器”简单地描述了这种区别。

我不得不查阅MVP才知道你在问什么。这个术语在1996年的一篇论文中使用。当OS X发布时，它仍然是新的。

- paulmelnikow