iOS开发中的传统MVC和MVC

简短明了，让我们直接看一下传统MVC和iOS中MVC的图表。

在传统的MVC中，视图对象可以通过采用“主观观察者”设计模式来注册模型对象的状态更改事件，一旦视图对象感兴趣的模型对象的状态更改，视图对象就会得到通知。

在iOS中，我们应该努力避免视图对象与模型之间的直接交互。 视图对象应始终通过控制器对象来了解模型对象中的更改。

好吧，就是这样。 以上是我想在本文中谈论的主要内容，但是如果您想获得更多详细信息，可以继续阅读。

Model-View-Controller是一种非常高级的体系结构设计模式，它认为存在三种类型的对象：模型对象，视图对象和控制器对象。 它定义了这些类型的对象在应用程序中扮演的角色及其通信线路。

模型是模式的核心组成部分。 它代表特殊的知识和专长，并根据问题域表达应用程序的行为。 它们保存应用程序的数据，并定义处理该数据的逻辑。 设计良好的MVC应用程序将其所有重要数据封装在模型对象中。 一旦将数据加载到应用程序中，任何属于应用程序持久状态的数据（无论该持久状态存储在文件还是数据库中）都应驻留在模型对象中。 因为它们代表与特定问题领域相关的知识和专长，所以它们倾向于可重用。

理想情况下，模型对象与用于呈现和编辑它的用户界面没有显式连接。 例如，如果您有一个代表一个人的模型对象（例如您正在写通讯录），则可能要存储生日。 存储在您的Person模型对象中是一件好事。 但是，存储日期格式字符串或其他有关如何显示该日期的信息可能更好。

视图对象知道如何显示，并且可能允许用户编辑应用程序模型中的数据。 该视图不应负责存储其显示的数据。 （当然，这并不意味着视图从不实际存储其显示的数据。出于性能原因，视图可以缓存数据或执行类似的操作）。 视图对象可以负责仅显示模型对象的一部分，整个模型对象甚至许多不同的模型对象。 视图有很多不同的种类。

视图对象倾向于可重用和可配置，并且它们在应用程序之间提供一致性。 在iOS中，UIKit框架定义了大量视图对象，并在Interface Builder库中提供了许多视图对象。 通过重用UIKit的视图对象（例如UIButton对象），可以确保应用程序中的按钮的行为与其他任何iOS应用程序中的按钮一样，从而确保了各个应用程序在外观和行为上的高度一致性。

控制器对象充当应用程序的视图对象与其模型对象之间的中介。 控制器通常负责确保视图可以访问他们需要显示的模型对象，并充当视图了解模型更改的渠道。 控制器对象还可以为应用程序执行设置和协调任务，并管理其他对象的生命周期。

在iOS MVC设计中，当用户输入值或通过视图对象指示选择时，该值或选择将传达给控制器对象。 控制器对象可能以某种特定于应用程序的方式解释用户输入，然后要么告诉模型对象如何处理此输入（例如，“添加新值”或“删除当前记录”），要么可能具有模型对象在其属性之一中反映了更改的值。 基于相同的用户输入，某些控制器对象可能还会告诉视图对象更改其外观或行为的某个方面，例如告诉按钮禁用自身。 相反，当模型对象发生更改时（例如，访问新的数据源），模型对象通常会将更改传达给控制器对象，然后控制器对象请求一个或多个视图对象进行相应的更新。

除了将应用程序分为三类之外，模型-视图-控制器设计还定义了它们之间的交互。

• 模型存储数据，该数据根据来自控制器的命令检索并显示在视图中。
• 视图基于模型的更改为用户生成新的输出。
• 它还可以向其关联的视图发送命令以更改视图的模型表示形式

以下准则适用于应用程序设计中的模型-视图-控制器注意事项：

• 设计良好的MVC应用程序的目标应该是使用（理论上至少）可重用的尽可能多的对象。 特别是，视图对象和模型对象应具有高度可重用性。 特定于应用程序的行为通常尽可能地集中在控制器对象中。
• 尽管可以使视图直接观察模型以检测状态变化，但是最好不要这样做。 视图对象应始终通过中介控制器对象来了解模型对象中的更改。
• 努力限制应用程序类中的代码依赖性。 一个类对另一个类的依赖性越大，可重用性就越差。 具体建议因所涉及的两个类别的MVC角色而异：

—视图类不应依赖于模型类（尽管某些自定义视图可能不可避免）。

—除其他模型类外，模型类不应依赖任何其他内容。