ios - 在模型- View - Controller 中， View 是否可以依赖于模型？

Question

关于模型- View - Controller (MVC) 的文献通常指出模型和 View 是相互独立的实体，而 Controller 调节它们的交互，因此强烈依赖于两者。

在理论上，最后一条陈述似乎是一种加强模块化的合理方法。

但假设您编写了一个允许用户创建、编辑和保存文档的应用程序。比简单的文本文档更复杂，这些文档由多个字段组成，并非都是同一类型。然后您想到，为了以多态方式支持同一文档的多种视觉表示，您可以定义一个 DocumentView 接口(interface)，任何具体的 View 子类都可以采用该接口(interface)来指示它能够显示文档。

现在，假设您已经编写了采用 DocumentView 接口(interface)的 SomeDocumentView 类。要创建文档 View ，您的应用程序代码将包含类似于下面的一行:

DocumentView documentView = SomeDocumentView(document)

现在假设将来您编写了 UpdatedDocumentView 类，它也采用了 DocumentView 接口(interface)。要进行更改，您只需将上面的行替换为:

DocumentView documentView = UpdatedDocumentView(document)

瞧!您的应用程序代码通过 DocumentView 接口(interface)自动支持您的 UpdatedDocumentView。

但是这样的设计不会违反 MVC，因为 View 的实现现在明确依赖于模型吗？为什么这必然是一件坏事？如果您的模型将来发生变化，无论采用何种方法，您都必须更改代码。

Answer 1

“ Model View Controller ”在不同的时间有不同的含义。在最初的 MVC 中，在 Smalltalk 中， Controller 表示用户输入，是的， View 采用模型对象并直接表示它们。

Apple's MVC更像是 MVP 的别名正如您所说，演示者/ Controller 充当模型和 View 之间的中间人。

此模式允许独立开发 View 。就您的 DocuentView 而言，它实际上可能是其他几个 View 的组合和 Controller ，因此模糊了 View 和 Controller 之间的区别。

UIViewController 被这样调用的原因之一是因为它处理许多 View 职责，即用户输入手势。不过，在现代代码中使用这些功能通常是不受欢迎的。 Apple 现在提供更多离散机制。