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