在模型 - 视图 - 控制器中，视图是否可以依赖于模型？

Question

关于模型 - 视图 - 控制器（MVC）的文献通常表明模型和视图是相互独立的实体，而控制器调解它们的相互作用，因此强烈依赖于两者。

在理论层面，最后一句话似乎是一种强制执行模块化的合理方法。

但假设您编写了一个允许用户创建，编辑和保存文档的应用程序。这些文档比简单的文本文档更复杂，由多个字段组成，而不是所有相同的类型。然后，您会想到，为了多态支持同一文档的多个可视化表示，您可以定义一个DocumentView接口，任何具体的视图子类都可以使用它来表明它能够显示文档。

现在，假设您已经编写了SomeDocumentView类，它采用了DocumentView接口。要创建文档视图，您的应用程序代码将具有类似于下面的行：

DocumentView documentView = SomeDocumentView(document)

现在假设您将来编写了UpdatedDocumentView类，它也采用了DocumentView接口。要进行此更改，您只需要将以上行替换为：

DocumentView documentView = UpdatedDocumentView(document)

瞧！您的应用程序代码通过DocumentView界面自动支持您的UpdatedDocumentView。

但是这样的设计是否违反了MVC，因为视图的实现现在明确依赖于模型？为什么这一定是件坏事？如果您的模型将来发生变化，则无论您的方法如何，都必须更改代码。

Answer 1

“模型视图控制器”在不同时间意味着不同的东西。在最初的MVC中，在Smalltalk中，控制器表示用户输入，是的，视图采用了模型对象并直接表示它们。

Apple's MVC更多是MVP的别名，正如您所说，演示者/控制器充当模型和视图之间的中间人。

此模式允许独立开发视图。可能在你的DocuentView的情况下，它实际上是几个其他视图的复合和控制器，因此模糊了视图和控制器之间的区别。

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