当我们构建我们的应用程序的 View Controller - View 架构时(我相信我使用这个词是正确的，因为它涉及对象之间的关系以及它们如何协同工作以及它们扮演什么角色，而不是我们使用什么框架等):
View 是一个 UIResponder，它接收触摸事件。 View Controller 也接收这些触摸事件。但是 View Controller 是一个 Controller 对象，响应触摸事件是 Controller 逻辑，所以 View Controller 应该负责根据触摸哪个 View 知道要做什么，对吧？
那么将所有触摸逻辑放在 View Controller 对象中而不是放在 View 对象中是更好的做法吗？本质上，忽略了 View 可以响应触摸这一事实。
如果我们将所有逻辑都放在 View Controller 对象中，是否为每个需要大量触摸逻辑的 View 配备一个 View Controller 对象是个好主意？因此，我们不是让一个 View Controller 将一堆 subview 作为界面元素，包含所有触摸交互代码，而是让每个 subview 成为其自己的 View Controller 对象的主视图，并让所有这些 View Controller 成为父 View 的 subview View Controller 。
这是一个好方法吗？
谢谢你的帮助
最佳答案
如果 View 要封装某种可重用的逻辑和状态，比如 UIButton 或 UITextField，那么 View 处理自己的触摸事件并将它们转换为 UIControlEvents 是有意义的，因为 viewController 实际上只关心事件而不是任何触摸细节的细节。在其他情况下，例如如果您允许在元素之间拖放，将此逻辑放在 viewController 中可能更有意义。在某些情况下，例如 UITableView，您拆分了差异并将尽可能多的通用功能放在 View 中，但将一些职责委托(delegate)给 ViewController 以允许自定义功能。
关于ios - 具有复杂触摸代码的 View 是否应该有自己的 View Controller ？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40554046/