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

Question

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

在理论层面上，最后一条陈述看起来像是一种强制模块化的合理方法。

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

现在，假设您已经编写了使用DocumentView接口的SomeDocumentView类。要创建文档视图，您的应用程序代码必须类似下面的一行：

DocumentView documentView = SomeDocumentView(document) 

现在，在未来的假设，你写的UpdatedDocumentView类，它也采用了DocumentView接口。要做出这样的改变，您只需要将上面的行替换为：

DocumentView documentView = UpdatedDocumentView(document) 

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

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

Answer 1

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

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

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

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