可可MVC≠实际MVC？

Question

今天，我得到了一些关于软件设计模式的更新。

我特别想知道Three-tier-layer.和MVC之间的区别。基本上，从我在维基百科和其他来源上所读到的信息来看，两者的主要区别在于组件之间的交互：

三层体系结构中的一个基本规则是客户层从不与数据层直接通信；

同时

...the MVC体系结构是三角形的:视图向控制器发送更新，控制器更新模型，视图直接从模型中更新。

现在:如果我们以苹果公司关于这件事的文件为例，我们可以看到：

​

他们还明确了视图和模型不应该直接通信：

视图对象通常与MVC应用程序中的模型对象分离。

和

当模型对象更改时(例如，通过网络连接接收新数据)，它会通知控制器对象，控制器对象更新适当的视图对象。

诸若此类。那么，这里怎么了？Cocoa是否采用了它自己的MVC概念，而不管哪个是普通的？或者，我是不是以常见的方式忽略了MVC架构？

Answer 1

虽然可以说Cocoa的MVC版本是MVC实际定义的一个子集，但它们并不是单独的实体。MVC的Cocoa版本通常围绕视图(通常是NSWindow和/或NSView)、控制器(通常是NSWindowController)和模型层(从简单数组到核心数据堆栈)的使用。这个模型中的三权分立是明确的，但是在Wiki定义的“层次”结构中，每一个都应该属于哪一个呢？

我认为Controller和View是客户层的一部分。控制器不仅负责模型和视图之间的委托，而且还负责响应用户事件并确定在非框架错误处理过程中要采取的正确操作。通过采用这种MVC方法，您现在可以开始了解Cocoa实际上是如何满足更广泛的模式定义的。

三层体系结构中的一个基本规则是客户层从不与数据层直接通信；

这一个可能是最难解释的第三个，它涉及深入研究什么是“沟通”实际上意味着什么的模式。当我们说到沟通时，我们的意思是控制器没有直接参与模型所采取的行动。这并不是说控制器不能命令更改模型的内容，而是说控制器没有参与模型更新的方式。控制器作为指导，而不是实现者，极大地简化了数据库层的创建，这也是核心数据和SQLite3作为外部框架而不是基础类存在的原因之一。

视图对象通常与MVC应用程序中的模型对象分离。

这带来了一个古老的禁忌在编程时的模式:让你的观点太聪明。控制器在模型和视图之间提供了一个坚实的屏障，因此控制器充当来自模型层的内容的指导和过滤器。如果没有任何这样的讨价还价者，比如一个表视图，就必须确保每个单元都有来自数据库的数据的副本，并且每个单元都知道何时以及如何在另一个单元中传播更改时更新自己。在可可，这就是我们的NSWindowControllers进来的地方。它们管理根视图的显示，并充当某个模型与其管理的视图的内容之间的屏障。不过，重要的是要注意，Cocoa中的控制器对象是视图偏倚的，这主要是因为在没有相当多不必要的胶水的情况下，几乎不可能为任何类型的模型层提供通用的接口。

当模型对象更改时(例如，通过网络连接接收新数据)，它会通知控制器对象，控制器对象更新适当的视图对象。

这就是我应该做的，因为我已经说明了这些原因。但是，为了在您给出的网络示例的基础上，考虑以下几个方面:给定一个获取数据的NSOperation和一个管理表视图的控制器，您可能不希望控制器将其肥硕的手指伸进操作，也不希望tableview接收原始的NSData，并且不得不花费宝贵的渲染时间来处理和显示结果。

诸若此类。那么，这里怎么了？Cocoa是否采用了它自己的MVC概念，而不管哪个是普通的？或者，我是不是以常见的方式忽略了MVC架构？

我想我会从中得出的结论是，您对MVC中的分权定义以及Cocoa如何做到这一点是不正确的。可可是相当严格的坚持模式，虽然有一个有趣的当代运动的目标-C社区走向MVVM。

Answer 2

你是正确的，MVC在大多数可可应用中的实践并不是MVC，因为它是在教科书中定义的。不同的框架使用的MVC有很多不同的版本。可视化设计器所使用的MVC受其可视化设计器实现的影响很大。有了XCode，你就有了故事板和笔尖。可可库和分离关切的方式受到这一因素的影响。如果您想利用这些工具，我建议您了解Xcode如何将关注点分离，并在这种方法中工作。您的代码将更顺利地与它共存。苹果的文档将在这方面有所帮助。

话虽如此，MVC是关于关注点的分离。在软件设计和维护中，分离关注点是非常重要的。适当地分离关注点可以减少依赖，降低圈复杂度，并使代码更易于测试和维护。我认为值得注意的是，您注意到了这一点，无论以什么方式构造MVC，都应该考虑将关注点作为实现指南的原因。