Cocoa MVC 真的不是 MVP 吗？答案

【问题标题】：Isn't Cocoa MVC really MVP?Cocoa MVC 真的不是 MVP 吗？
【发布时间】：2013-02-18 19:15:02
【问题描述】：

又是一个与 MVC 相关的问题。几天前，我开始阅读 Apple 的 Cocoa Fundamentals Guide，其中 Apple 解释了他们的 MVC 实现。

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

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

此复合设计模式中的控制器对象包含中介者模式和策略模式；它调解流程模型和视图对象之间的双向数据。 变化模型状态通过控制器传递给视图对象 应用程序的对象。

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

我完全错了，我误解了 MVC 还是 MVP？还是 Apple 只是为这种模式使用了错误的名称？更重要的是，为什么现在的这种模式叫 MVC？

【问题讨论】：

【解决方案1】：

你没有错，Apple 文档的作者也没有错。

MVC 的历史现在漫长而复杂——尤其是因为许多系统提倡三方分离，这实际上将控制器混入模型中或将控制器混入视图中。从早期的 Smalltalk 实现中，很明显将模型信息隐藏在视图之外是一件非常好的事情，而且这很容易做到。

另一方面，将控制器和视图的职责清晰地分开并不那么简单。许多视图都希望被重用，例如按钮或文本字段。他们的控制器的可重用部分也希望被重用。但是您不会按下文本字段或加粗按钮；许多按钮行为与视图密切相关。同时，很难确定业务规则何时属于模型以及何时属于控制器。

此外，这份（非常好的）Apple 文档试图捕捉一种哲学设计理念，而不是描述 The One True Way。许多 Cocoa 控制器子系统看起来很像传统的 MVC。传统的 Cocoa 不再强调控制器，因此本文档实质上是在主张让它们在（可重用的）视图和（潜在的可重用的）模型之间作为中介。

许多 Cocoa 实现者更喜欢瘦控制器，本质上是作为外观来解耦视图和模型。

【讨论】：

好答案。即使是可可的好部分也跨越了这些界限。 NSImage 出于性能原因封装了控制器行为，例如故障和缓存，并且 NSImageView 可能会在不咨询中介控制器的情况下要求图像调整大小的表示。此外，拥有 NSImageView 是完全合理的，它是为特定模型类构建的视图。此外，Apple 文档提到了 Cocoa Bindings，但暗示它们是视图和模型之间的无中介连接。我通常只是将绑定本身视为中介控制器，尤其是考虑到消息流。
不错的答案。我认为这更多的是展示一般的良好实践，而不是定义一种准确且始终正确的设计方式。 MVC 并没有停留在一个定义中，而是展示了一种关于如何开发应用程序的灵活/抽象的想法。感谢您的宝贵时间。

【解决方案2】：

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

Apple 称它为中介控制器——我综合起来——只是 MVP 的另一个名称。

坦率地说，我不确定 MVP 这个词是否应该流行起来。这意味着它是一种完全不同的模式，并且 presenter 似乎专注于 UI，而有时它只是模型和控制器之间的关系。 中介控制器非常简单地描述了这种区别。

我不得不查看 MVP 甚至知道你到底在问什么。该术语在 1996 年的一篇论文中使用。当 OS X 发布时，它仍然是新词。

【讨论】：