UIView 或 UIViewController 子类？答案

【问题标题】：UIView or UIViewController subclass?UIView 或 UIViewController 子类？
【发布时间】：2013-07-04 12:28:17
【问题描述】：

我正在尝试以最好的方式重构我的代码，我想知道在给定情况下的正确架构是什么。

我想做的事

我所做的非常简单：我有一些自定义的CALayer 子类，它们代表一个交互式 UI 元素。由于 UI 的某些部分是静态的，因此它们被分解为多个层，因此我不想不必要地重绘这些静态元素。现在，这些层作为子层添加到CustomView 类的初始化部分，该类是UIView 的子类。

目前没有对应的CustomViewController 类是UIViewController 的子类，因为当我使用CustomView 时，它包含在UITableViewCell 或a 的一部分中通用 UIViewController 与其他视图，所以我觉得每个 CustomView 实例的另一个 UIViewController 是多余的。

同样重要的是，我在 UIView 类中所做的唯一操作是响应触摸事件并将触摸信息发送到子层，以便 UI 可以相应地更新其外观。我没有覆盖drawRect 方法或类似的方法。

问题

基本上，我想弄清楚我是否应该这样做：

选项 1：

摆脱CustomView 类，创建一个CustomViewController 类作为UIViewController 的子类，并简单地将CALayer 对象添加为CustomViewController 的内置view 的子层属性。

或

选项 2：

我认为 UIViewController 子类是多余的是正确的，所以我应该保留它的原样，并在其中包含 CALayer 对象的 CustomView 类。

我非常感谢您对此提出任何建议。

【问题讨论】：

我做的和你过去做的完全一样。我也用 UIViewController 完成了它。只要代码是可维护的和高性能的，那么我想这并不重要。 UIViewController 是（我猜）更“正确”的方法，但它也可能会影响性能，特别是如果你将它放在 UITableViewCell 中并且可能有很多。
感谢您的快速回复。很高兴听到我不会采用目前实施的非UIViewController 方式。

标签： ios model-view-controller uiview uiviewcontroller calayer

【解决方案1】：

我认为就 MVC 而言，您所描述的代码（选项 #2）写得很好，并且保持了非常明确的责任边界。您不会在此类中编写任何与视图层本身无关的代码，这很棒。我认为在这种情况下，不需要单独的 UIViewController 子类来管理这些实例，因为正如您所说 - 他们正在处理自己的触摸事件和可见层（完全是他们的责任）。

如果出于任何原因需要更复杂的东西，需要与数据相关的逻辑或其他此类计算，我肯定会考虑将UIViewController 子类化，或者以完全不同的方式看待问题。

鉴于您提出的情况，我认为在此 UIView 子类（'CustomView'）中维护 CALayer 实例是正确的方法。

【讨论】：

感谢您的回复！尽管尚未实现，但 UI 元素将根据从 iCloud 保存/加载的信息进行动画处理。你认为既然我将使用 iCloud，我应该实现选项 1 中描述的UIViewController 方法吗？选项 1 的替代方案是执行 CustomView *cv = [[CustomView alloc] initWithData: elementData]; 之类的操作，其中 elementData 已由 UITableViewController 等加载。但是，该替代方案可能会破坏 MVC 概念，因为它将视图与模型混合在一起。
在我看来，UIView 的子类不应该有 'initWithData' 方法——这无疑与 MVC 范式相矛盾。如果要从 iCloud 下载数据，可能需要考虑更复杂的事情。另一方面，我看到很多处理缓存的 UIImageView 子类，例如缓存与存储有关（与视图元素没有任何关系）。这件事有明确的“正确”和“错误”，但保持可理解的代码很重要。
在我发布之后，我认为与其给 UI 元素提供实际数据，不如使用一个方法来设置元素应该动画到的任意整数。比如设置UITableViewCell时，我可以这样做：[[CustomView alloc] initWithValue: data.integerValue];其中data是UITableViewController已经加载的iCloud数据，integerProperty是直接对应外观的值用户界面元素。我认为这将保持 MVC 范式的完整性。
不错，听起来很公平