iOS：关于不复制 MVC 模型中的视图层次结构答案

【问题标题】：iOS: On not duplicating the view hierarchy in the MVC modeliOS：关于不复制 MVC 模型中的视图层次结构
【发布时间】：2014-08-13 15:34:09
【问题描述】：

这个问题与 MVC（在 iOS 编程中）有关，以及作者使用 MVC 的一本书与我之前看到的相比不同。

我认为我对 Apple 对 MVC 模式的解释非常清楚，正如斯坦福大学关于 iOS 编程的在线课程中所解释的那样。也就是说Model和View应该是独立的，Controller应该起到胶水的作用介于两者之间。

我已经实现了一些 iOS 应用程序，其中视图包含可移动对象。在此过程中，可移动对象已被实现为子视图（或 CALayer:s），并且它们已由主视图实例化。子视图知道它自己的位置和大小（在框架属性中），但该信息通常在我的模型对象中重复。事实上，整个视图层次结构通常在模型中表示（我将我的 spagetti 编码大部分归咎于这种冗余）。

在开始 iOS 游戏开发一书中，作者 Patrick Alessi 实现了一个名为 Blocked（a.k.a breakout）的游戏。在他的实现中，模型分配并初始化 UIView 对象数组（突破游戏中的块），然后控制器将它们添加到视图中。当稍后的块应该消失时，模型会将其从父视图以及数组中删除。

我对 Alessi 的实施有复杂的感觉。它避免了数据的重复！但是它与 MVC 有什么关系呢？我问这个问题是为了拓宽我自己对 MVC 的理解。是否可以将 UIView 对象同时视为视图和模型对象？

【问题讨论】：

标签： ios objective-c model-view-controller

【解决方案1】：

嗯，它是一个游戏而不是一个信息处理应用程序。该模型实际上与视图密切相关，因为您关心块在屏幕上的位置，以便您可以计算它们是否被击中等等。 3D 射击游戏也是如此，其中大多数信息都涉及在 3D 空间中某个位置的事物。只需确保您设法重构了大多数不直接涉及从 UIView 子类中绘制视图的代码。

得分、玩家数据和广告等内容应该使用传统的 MVC 模型。

【讨论】：

【解决方案2】：

应用程序在视图层次结构中拥有每个模型对象的表示是很常见的。

正如你所说，胶水属于控制器。如果我正在编写突围游戏，我会将创建视图对象数组的逻辑放在控制器中。

在游戏应用中，扩展甚至放弃 MVC 设计模式可能是有意义的。模型对象（一块砖）可以同时是一个视图对象。控制器将直接管理一组积木，其中管理将涉及更新积木的坐标、它们的屏幕上/屏幕外状态等。这可能是我处理此类游戏的方式。

【讨论】：

【解决方案3】：

SmallTalk 最初被认为是模型视图，控制器角色在 Objective-C 将该语言与 C 结合之前自然演变。我认为相应地，您可以在一定程度上将控制器视为目的不那么具体；当然它是在两个组件之间提供一些抽象，但因此必须应用避免冗余抽象的一般原则。

极端示例：您的模型对象是NSString。您希望能够在屏幕上放置字符串。您已经获得了渲染单个字符的代码；这显然是一个观点。 NSString 可以提供其字符列表；这显然是一个模型。您真的需要一个正式的、单独的控制器类来将字符一个一个地喂给一个或多个视图吗？有一个有用吗？

我认为大多数人因此允许视图可以整体呈现模型对象的场景，即使它是比字符串复杂得多的复合物。假设您有一个包含姓名和电话号码的地址簿对象。大多数人会允许视图接收该对象并组成子视图以在内部显示。通常这意味着视图直接与模型对话，并且可能模型为视图做一些工作——如果视图需要电话号码，那么它为什么要关心该属性是否实现为@dynamic？如果模型从标准存储属性演变为需要更复杂查找的东西，那为什么会涉及到视图的更改？

然后控制器主要负责组成完整的界面。它将组成部分粘合在一起，以允许可渲染对象的集合形成连贯的显示。

和你一样，我会对 Alessi 允许模型直接操作视图层次结构产生严重疑虑。模型绝对不应该让自己参与到视图中。有责任在视图上显示模型内容，而控制器在解耦有意义的地方解耦。

【讨论】：