关于模型-视图-控制器(MVC)的文献一般认为模型和视图是相互独立的实体，而控制器调节它们的交互，因此强烈依赖于两者。
在理论层面上，最后一条语句似乎是一种强化模块化的可靠方法。
但是假设您已经编写了一个允许用户创建、编辑和保存文档的应用程序。这些文档比简单的文本文档更复杂，它们由多个字段组成，而不是所有字段都是相同的类型。然后你想到，为了多态地支持同一文档的多个可视化表示，你可以定义一个DocumentView接口，任何具体的视图子类都可以采用它来表明它能够显示文档。
现在，假设你已经编写了SomeDocumentView类，它采用了DocumentView接口。要创建文档视图，您的应用程序代码将包含如下所示的一行:DocumentView documentView = SomeDocumentView(document)
现在假设在将来，您已经编写了UpdatedDocumentView类，它也采用了DocumentView接口。要进行更改，您只需要将上面的行替换为:
DocumentView documentView = UpdatedDocumentView(document)
瞧!你的应用程序代码通过DocumentView接口自动支持你的UpdatedDocumentView。
但是这样的设计是否违反MVC，因为视图的实现现在显式地依赖于模型?为什么这一定是件坏事呢?如果将来您的模型发生了变化，那么无论采用何种方法，您都必须更改代码。
"Model - View - Controller"在不同的时间有不同的含义。在最初的MVC中，在Smalltalk中，控制器表示用户输入，是的，视图接受模型对象并直接表示它们。
苹果的MVC更像是MVP的别名，正如你所说，呈现者/控制器充当模型和视图之间的中间人。
该模式允许独立开发视图。可能在你的DocuentView的情况下，它实际上是几个其他视图的复合和控制器，从而模糊了视图和控制器之间的区别。
UIViewController被称为这样的原因之一是因为它处理许多视图的职责，即用户输入手势。但是，在现代代码中使用这些特性通常是不受欢迎的。苹果现在提供了更多的离散机制