objective-c - 在 iOS 中将 View Controller 与 View 分开是否有意义？

Question

我有 Web 开发背景，主要开发基于 MVC 的应用程序，我习惯于将我的代码组件分成三组文件: Controller 、模型和 View 。

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

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

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

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

Answer 1

诚然，我们中的许多人都会稍微模糊 MVC 的界限，并将少量与 View 相关的代码放入我们的 Controller 中。我个人认为这很好。它并没有削弱我们仍然主要遵循 MVC 模式的事实(并且 Cocoa 类正在为 View 做繁重的工作)。但是，对我来说，如果与 View 相关的代码超出了琐碎的范围，我发现自己选择对 View 进行子类化。

会有人虔诚地继承UIView，但我认为有一点实用主义是必要的。如果您要添加少量与 View 相关的代码，是否通过将其抽象到新的 UIView 子类中来提高代码的易读性？不总是。但我认为这种情况(有人在他们可能不需要的时候进行子类化)远不如相反的问题(有人在他们可能应该有的时候没有进行子类化)常见。

所以，你问:

I do not see the need for doing that [subclassing UIView], unless of course you are reusing the same UIView in several places or doing custom drawing.

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

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

2. 我越来越多地将 UITableViewCell 子类化为我的 TableView 。在我的第一个项目中，我会让 TableView Controller 的 cellForRowAtIndexPath 完成该单元格的所有复杂组合和布局。现在我的代码更容易理解，因为我在任何不使用标准单元格类型的情况下都例行地将 UITableViewCell 子类化。

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

归根结底，虽然您不需要一直对 View 进行子类化，但我个人认为许多开发人员都犯了未能在应有的情况下对 View (或模型)进行子类化的错误。他们这样做不应该出于某种遵循 MVC 的狂热愿望，而是他们应该问自己，如果他们适本地对 View 或模型进行子类化，他们的代码是否会更易于阅读和维护。