但是,我经常遇到这样的情况：我将拥有一个视图层次结构,其中子视图的某个子视图有一个发送网络请求的按钮.在那种情况下,我可以做一个目标：
myView.addTarget(self,action: "networkRequest:",forControlEvents: UIControlEvents.TouchDown)
然后在同一个myView类中我可以处理该网络请求,但这似乎打破了MVC模式. View不应该做逻辑,他们应该只显示东西,对吗？
我们可以做的另一个选择是让每个视图都可以访问逻辑所需的父控制器或祖父控制器.在我的目标可能看起来像这样的情况下：
func networkRequest(view : MyView) {
self.controller.doNetworkRequest()
}
但这似乎也不是一个正确的解决方案.再一次,看起来我们只是打破了MVC并且萎缩了.
所以相反,就我所见,我们只剩下两种选择之一：
首先,我们可以从父控制器本身添加目标和所有逻辑.但这样做会给我们这样讨厌的链条：
self.grandParentView.parentView.childView.addTarget(self,forControlEvents: UIControlEvents.TouchDown)
那长长的访问列表让我感到寒意,看起来很糟糕.但是,它似乎仍然遵循MVC.从技术上讲,我们在控制器中执行逻辑,对吗？
但可能还有另一种选择.我们可以给每个视图一个控制器,让每个UIViewController都有一个子控制器用于每个新的子视图.
但是,有些观点是静态的.它们实际上没有任何逻辑,因此它们不一定需要控制器.但是,如果我们要遵循这个约定,我们基本上需要每个视图一个,否则我们会有一个不一致的地方,控制器有一个孙子控制器,但没有子控制器.
所以我们为控制器创建了很多空的棺材.这会构建许多永远不会被使用的死代码,这会导致一些软件腐烂.
解决方法
选项1 – 失败
如果您正在处理UIView子类中的网络请求,那么您肯定会破坏MVC模式.根据Apple的MVC参考：
A view object is an object in an application that users can see. A view object kNows how to draw itself and can respond to user actions.
如图所示,视图应该只是处理用户可以看到和与之交互的内容.不要走这条路.
选项2 – 成功
让我们回到Apple的视图控制器的MVC参考：
A controller object acts as an intermediary between one or more of an application’s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.
请注意文档如何说“一个或多个”,因为视图控制器可以完全接受处理多个视图的后勤.就个人而言,我会说,如果您的视图只有一个按钮需要网络请求的委托,请继续并将父视图的视图控制器设置为委托.
一旦视图的数据处理变得“复杂”,您应该让视图拥有自己的视图控制器,为了简明起见,我将其定义为“多个操作,它们将掩盖父视图的视图控制器的明显目的”.
话虽这么说,有可能在视图控制器中用#pragma标记清楚地标记为什么代码就在哪里,所以在这里使用你的判断.
选项3 – Ehhh ……
给每个视图自己的视图控制器绝对可行,但你真的认为有必要吗？如果应用程序是扩展的,每次需要处理单个按钮时创建一个全新的视图控制器似乎有点矫枉过正.
总结一下
使用选项#2并使用您的最佳判断.你不能因为打破MVC模式而受到惩罚.最糟糕的是,如果视图的逻辑变得复杂,您将把代码重构为新的视图控制器.
更多参考：
Model-View-Controller – iOS Developer Library
希望这可以帮助！
