如何区分 View 中的代码和 ViewController 中的代码？ [关闭]答案

【问题标题】：How to differentiate what code put in View and what in ViewController? [closed]如何区分 View 中的代码和 ViewController 中的代码？ [关闭]
【发布时间】：2020-06-10 19:43:39
【问题描述】：

我在我的UIView 子类中有相当大的目标操作实现，所以我的视图文件（来自 MVC）似乎有一些代码，这与在屏幕上安排UIView 对象没有真正的联系。这是遵循 MVC 模式的正确方法吗？如果没有，正确的处理方法是什么？

【问题讨论】：

如果你能展示一下这个“代码......与排列 UIView 对象没有真正联系”是什么，那将会有所帮助。或许是Model材质，或许是Controller材质，但不展示怎么知道呢？即使这样，这也可能是一个基于意见的问题，但目前您所指的内容纯粹是猜测。还要记住，MVC 并不是唯一的哲学。

标签： ios swift model-view-controller

【解决方案1】：

我不会谈论 MVC 的正确实现，因为这是一个详尽的主题，可以在整个互联网上找到。就个人而言，我喜欢将我所有的视图代码封装在 UIView 的自定义视图子类中，并使用 ViewController 来管理交互、委托、数据源和其他事件。

class CustomView: UIView {
  func addSubviewsToView()
  func configureLayout()
}

class CustomViewController: UIViewController {
  var childView: CustomView!

  func addCustomViewToViewControllerView()
  func addTargetsAndGestureRecognizers()
  func configureAnyViewDelegates()
  func configureAnyDataSources()
}

可能有一个冗长的自定义视图类或冗长的视图控制器。这不一定是问题。如果没有管理您的选择的组织模式，这可能会成为一个问题。

this GitHub 存储库中粗略地概述了一种用于区分视图和控制器代码的有趣组织模式。

我使用了这个概念中的一些片段来帮助自己组织视图和控制器代码。希望这会有所帮助。

【讨论】：

【解决方案2】：

这完全取决于这些目标操作在做什么。

如果它们与视图相关（例如，用于拉出菜单、向后滑动、移动子视图等的控件），那么将所有这些都封装在视图类中可能是合理的。
李>
但是，如果这些操作包括业务逻辑、网络请求、本地数据存储操作等，那么将它们放在UIView 子类下可能与您应该做的完全相反。

就构建应用程序的模式而言，有许多替代方案，包括：

请参阅 Dave Delong 的 A Better MVC，了解采用 MVC 的观点，但采用技术使其小型化且易于管理。
请参阅 Medium 的 iOS Architecture Patterns，了解其他方法，包括 MVP、MVVM、Viper 等。
请参阅 Krzysztof Zabłocki 的 iOS Application Architecture，了解有关该主题的另一个很好的讨论。

我不会把我的拇指放在规模上并提倡一种特定的模式而不是另一种（这是一个见仁见智的问题，因此与 Stack Overflow 无关），但是当你经历所有以上，一致的主题是职责分离，使我们的代码更容易推理，并提高了可测试性。

底线，将特定于视图的代码移动到您的 UIView 子类中很好，但是将业务/应用程序逻辑放入视图是一种反模式。

【讨论】：