许多视图具有子视图，这些子视图不一定需要具有与之关联的自己的控制器。在Apple自己的有关创建自定义视图的教程中，他们实际上并未为每个子视图创建一个子UIViewController。
但是，通常我会遇到这样的情况，我将拥有一个视图层次结构，其中子视图的某些子视图具有发送网络请求的按钮。在这种情况下，我可以做一个目标：
myView.addTarget(self, action: "networkRequest:", forControlEvents: UIControlEvents.TouchDown)
然后在同一个myView类中，我可以处理该网络请求，但这似乎破坏了MVC模式。视图不应该执行逻辑，它们应该只显示内容，对吗？
我们可以做的另一种选择是让每个视图都可以访问其逻辑所需的父或祖父母控制器。在这种情况下，我的目标可能类似于：
func networkRequest(view : MyView) {
self.controller.doNetworkRequest()
}
但这似乎也不是正确的解决方案。同样，似乎我们只是在打破MVC并弱化了。
因此，据我所知，我们剩下两个选项之一：
首先，我们可以从父控制器本身添加目标和所有逻辑。但是这样做会使我们像这样讨厌的链条：
self.grandParentView.parentView.childView.addTarget(self, action: "networkRequest:", forControlEvents: UIControlEvents.TouchDown)
如此漫长的访问清单让我感到寒战，而且看起来很糟糕。但是，它似乎仍然遵循MVC。从技术上讲，我们正在执行控制器中的逻辑，对吗？
但是可能还有另一种选择。我们可以给每个视图一个控制器，让每个UIViewController为每个新的子视图都有一个子控制器。
但是，有些观点是静态的。它们实际上没有任何逻辑，因此它们不一定需要控制器。但是，如果要遵循此约定，则基本上每个视图都需要一个视图，否则，在控制器具有孙子控制器但没有子控制器的情况下，我们将存在不一致之处。
因此，我们只剩下为控制器创建许多空棺材了。这会堆积很多无法使用的无效代码，这可能会导致一些软件崩溃。
因此，比我更聪明和明智的人，这里的正确解决方案是什么？
可能有MVC专家比我聪明，但我会加以说明：
如果要在UIView子类中处理网络请求，则肯定会破坏MVC模式。根据Apple的MVC参考：
视图对象是用户可以看到的应用程序中的对象。视图对象知道如何绘制自身，并且可以响应用户的操作。
如图所示，视图应该只是处理用户可以看到并与之交互的内容。千万不能走这条路线。
让我们回到关于视图控制器的Apple MVC参考：
控制器对象充当一个或多个应用程序的视图对象与其一个或多个模型对象之间的中介。因此，控制器对象是一个通道，视图对象通过该通道了解模型对象的变化，反之亦然。控制器对象还可以为应用程序执行设置和协调任务，并管理其他对象的生命周期。
请注意该文档怎么说“一个或多个”，因为视图控制器处理多个视图的物流是完全可以接受的。就个人而言，我想说的是，如果您的视图只有一个需要网络请求委托的按钮，请继续将父视图的视图控制器设置为委托。
一旦视图的数据处理变得“复杂”，就应该让一个视图拥有自己的视图控制器，为简洁起见，我将其定义为“将使父视图的视图控制器的明显目的模糊的多个动作”。
话虽如此，有可能在视图控制器中清楚地标记#pragma mark代码的确切位置，因此请在此处使用您的判断。
为每个视图提供自己的视图控制器绝对是可行的，但是您真的认为有必要吗？如果应用程序扩展，每次您需要处理单个按钮轻击时创建一个全新的视图控制器肯定显得过高。
选择选项＃2，并运用最佳判断。您不会因破坏MVC模式而受到惩罚。最糟糕的是，如果视图的逻辑变得复杂，您将把代码重构到新的视图控制器中。
希望这可以帮助！
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句