在 iOS 中将视图控制器与视图分开是否有意义？

Question

来自 Web 开发背景，主要从事基于 MVC 的应用程序，我习惯于将代码的组件分成三组文件：控制器、模型和视图。

但是在 iOS 应用程序中，即使也使用 MVC 模式，遵循相同的技术是否有意义？

AnUIViewController为您提供了一个默认视图，您可以在其中添加其余的子视图 ( UILabel, UIButton,...) 并立即访问它们。语言是一样的，它不像必须处理 HTML/CSS 和其他东西。

但是我遇到过一些 iOS 应用程序，其中 anUIView被子类化并保存在一个单独的文件中，即使它只在UIViewController. 因此，您必须编写自定义访问器来处理内部子视图。

我认为没有必要这样做，除非您UIView在多个地方重复使用相同的内容或进行自定义绘图。

Answer 1

诚然，我们中的许多人会稍微模糊 MVC 的界限，并将少量与视图相关的代码放入我们的控制器中。我个人认为这很好。这并没有削弱我们仍然在很大程度上遵循 MVC 模式的事实（并且 Cocoa 类正在为视图做繁重的工作）。但是，对我来说，如果与视图相关的代码扩展到无关紧要的范围之外，我会发现自己选择对视图进行子类化。

会有人虔诚地子类化UIView，但我认为有点实用主义是有必要的。如果您要添加少量与视图相关的代码，是否通过将其抽象为新的UIView子类来提高代码的易读性？不总是。但是我认为这种情况（某人可能不需要子类化时）远不如相反的问题（某人可能应该有子类化时却未能进行子类化）常见。

所以，你问：

我认为不需要这样做 [子类化 UIView]，当然除非您在多个地方重用相同的 UIView 或进行自定义绘图。

我同意重用和自定义绘图（例如drawRect）是两个很好的例子。但我还要添加一个原则，如果由于视图足够复杂（诚然是主观调用），子类化会提高代码易读性，那么我将子类化。两个例子：

1. 我在应用程序中有一个日历视图，视图控制器变得笨拙，管理一个月中不同天的所有单元格，等等。因此，通过子类化UIView，我能够抽象出所有子视图的丑陋细节由日历视图组成。我不仅对主要的“月”视图进行了子类化，还对“月”视图中的“日”视图进行了子类化。本身没有重用。没有自定义绘图。但这显然是正确的做法。代码更加清晰易读。

2. 我越来越多地UITableViewCell为我的表视图创建子类。在我的第一个项目中，我让表格视图控制器cellForRowAtIndexPath完成该单元格的所有复杂组合和布局。我的代码现在更容易遵循，因为我经常UITableViewCell在我不使用标准单元类型之一的任何情况下对进行子类化。

简而言之，虽然我同意人们不应该感到被迫UIView为每个视图控制器子类化 a ，但我个人尝试在视图达到某种复杂程度时这样做。我让代码易读性支配我的实践。我发现我比以前更多地对视图进行子类化，但绝不是我一直在这样做。

最重要的是，虽然您不需要一直对视图进行子类化，但我个人认为许多开发人员在应该拥有的时候未能对视图（或模型）进行子类化而感到内疚。他们不应该出于遵守 MVC 的狂热愿望而这样做，而是应该问自己，如果他们适当地对视图或模型进行子类化，他们的代码是否更易于阅读和维护。