来自 web 开发背景，主要做基于 MVC 的应用程序，我习惯于将代码的组件分成三组文件：控制器、模型和视图。
但是在 iOS 应用程序中，即使也使用 MVC 模式，遵循相同的技术是否有意义？
AnUIViewController为您提供了一个默认视图，您可以在其中添加其余的子视图 ( UILabel, UIButton,...) 并立即访问它们。而且语言是一样的，不需要处理 HTML/CSS 和其他东西。
但是我遇到了一些 iOS 应用程序，其中 anUIView被子类化并维护在一个单独的文件中，即使它只用于UIViewController. 因此，您必须编写自定义访问器来处理内部子视图。
我认为没有必要这样做，除非您UIView在多个地方重复使用相同的内容或进行自定义绘图。
诚然，我们中的许多人会稍微模糊 MVC 线条，并将少量与视图相关的代码放入我们的控制器中。我个人认为这很好。这并没有削弱我们仍然在很大程度上遵循 MVC 模式的事实（并且 Cocoa 类正在为视图做繁重的工作）。但是，对我来说，如果与视图相关的代码超出了琐碎的范围，我发现自己选择子类化视图。
会有人在宗教上分等级UIView，但我认为有一点实用主义是有道理的。如果您要添加少量与视图相关的代码，是否通过将其抽象为新的UIView子类来提高代码的易读性？不总是。但我认为这种情况（有人在他们可能不需要子类时进行子类化）远不如相反的问题（有人在他们可能应该有子类时未能子类化）常见。
所以，你问：
我认为没有必要这样做 [子类化 UIView]，除非您在多个地方重用相同的 UIView 或进行自定义绘图。
我同意重用和自定义绘图（例如drawRect）是两个很好的例子。但我还要添加一个原则，如果子类化会提高代码的易读性，因为视图足够复杂（当然是主观调用），那么我将子类化。两个例子：
我在应用程序中有一个日历视图，视图控制器变得笨拙，管理一个月中不同日子的所有单元格，等等。所以通过子类化UIView，我能够抽象出所有子视图的丑陋细节由日历视图组成。我不仅对主要的“月”视图进行了子分类，还对“月”视图中的“日”视图进行了分类。本身没有重用。没有自定义图纸。但这显然是正确的做法。代码更加清晰易读。
我越来越多地UITableViewCell为我的表格视图子类化。在我的第一个项目中，我会让表格视图控制器cellForRowAtIndexPath完成该单元格的所有复杂组合和布局。现在我的代码更容易理解了，因为UITableViewCell在我不使用其中一种标准单元格类型的任何情况下，我都会例行地将其子类化。
简而言之，虽然我同意不应该被迫UIView为每个视图控制器子类化 a，但我个人尝试在视图达到一定复杂程度时这样做。我让代码易读性支配我的实践。我发现我比以前更多地对视图进行子类化，但绝不是我一直都在这样做。
归根结底，虽然您不需要一直对视图进行子类化，但我个人认为许多开发人员在应该有子类化视图（或模型）时犯了错。他们不应该出于某种符合 MVC 的狂热愿望而这样做，而是他们应该问自己，如果他们适当地对视图或模型进行子类化，他们的代码是否更易于阅读和维护。
通常，我会有一个UIViewController<=> SingletonManager <=> 实际数据源。我更喜欢把事情分开。如果我碰巧有一个 custom UIView，我在其中进行自己的自定义绘图，我将为此创建一个不同的文件，因为它是有意义的。即使我只在一个地方使用（你永远不知道明天需要什么，而且你可能碰巧在其他地方需要它）。也不要忘记你实际上已经在 iOS 中很好地分离了 MVC：
当您处理 iPhone 和 iOS 上的同一应用程序之间的差异时，这可能是一个很好的模式。iPad 上的 DetailViewController 可能是 iPhone 上的 UINavigationController。
另一个常见的模式是控制器与 DataSource 耦合，而视图与 DataSource 无关，并且可以在多个控制器中重用。
视图不在视图控制器中，它们要么在单独的类中，要么在视图控制器加载的 nib 文件中，视图控制器是为该视图编写的，因此它将所有操作和出口连接到该视图。
现在，如果您询问使用 nib 或子类，在组合和继承之间进行选择是一样的。
如果你需要一个特殊的视图，子类化 UIView，但是如果你想拥有一个带有控件作为子视图的视图，使用组合并且使用 Interface Builder 来组合你的视图更容易。
我看到只有子视图的 UIView 子类的唯一原因是为了更好的封装，但是因为您的控制器是专门为视图编写的，所以不需要这种封装。