从我记事起，我就一直在制作 iOS 应用程序，但直到最近我获得实习编程时，我的编程风格还没有成熟多少。我很早就学习了许多 OO 概念，因为我意识到如果不了解它们，生活就会很糟糕，但是我从未让自己学习的一件事是 MVC 模式。
为了给出上下文，假设我正在单个SolarSystemView（的子类UIView）内绘制一个太阳系。我应该SolarSystemView有一个类的实例变量SolarSystem（一个包含具有所有重要行星和恒星属性的数据结构的类），还是应该归 a 的实例所有SolarSystemViewController？还是完全不同的东西？我找不到任何给出满意答案的示例代码。
我想如果视图拥有模型，操作会非常流畅，但这也感觉不是很好的风格。毕竟，SolarSystem实例必须以某种方式动态更改，并且以与更新相同或相似的速率SolarSystemView。
在 MVC 范式中，模型应该与视图分离。为了获取它需要自己绘制的数据，它向 Controller 请求它，而后者又向 Model 请求它。这样，我们将信息与 GUI 分离。如果有帮助，可以将其视为模型控制器视图。因此，在大多数情况下，控制器“拥有”模型。
例如，在 cs193p 中，CalculatorViewController(Controller) 具有CalculatorBrain(Model) 属性，它与之交互以获取方程式的结果以显示在视图中。
在您的特定示例中， theSolarSystemViewController可能对 有一个强引用SolarSystem，它会轮询它将移交的数据，SolarSystemView以便它可以在需要更新时自行绘制。还可能在用户与其交互时SolarSystemView通知SolarSystemViewController，以便它可以显示其他视图或更新SolarSystem，以及它可以执行的任何其他任务。
请注意，Cocoa 和 Cocoa Touch 中的 MVC 范例与其他更通用的 MVC 版本（如 Smalltalk）略有不同。例如，如果您查看MVC 上的 Wikipedia 页面，那里的图表应该与您所学的有所不同。事实上，GoF（设计模式）就是这样描述 MVC 的。
MVC 由三种对象组成。模型是应用程序对象，视图是它的屏幕呈现，控制器定义了用户界面对用户输入的反应方式。在 MVC 之前，用户界面设计倾向于将这些对象集中在一起。MVC 将它们解耦以增加灵活性和重用性。MVC 通过在它们之间建立订阅/通知协议来解耦视图和模型。视图必须确保其外观反映模型的状态。每当模型的数据发生变化时，模型都会通知依赖它的视图。作为响应，每个视图都有机会进行自我更新。这种方法允许您将多个视图附加到模型以提供不同的表示。您还可以为模型创建新视图而无需重写它。
在这两种情况下，模型本身都在联系视图以更新它。但是，在 iOS 上，Model 和 View 之间的交互是通过 Controller 处理的。这在cs193p 的第一个会话以及Apple 自己的 MVC 关系文档中得到了很好的解释。这样，您只需要重写控制器代码即可在其他地方重用模型和视图。
这是来自 cs193p 的 MVC 图来澄清。
在这种情况下，SolarSystemView 不应包含 SolarSystem 类的任何瞬间。SolarSystemViewController 应该是您的视图 (SolarSystemView) 和模型 (SolarSystem) 之间的连接。