在iOS中,每个UIView都应该有一个UIViewController吗？

Question

许多视图的子视图不一定需要将自己的控制器与它们相关联.在Apple 自己的创建自定义视图的教程中,他们实际上并没有为每个子视图创建一个子UIViewController.

但是,我经常遇到这样的情况:我将拥有一个视图层次结构,其中子视图的某个子视图有一个发送网络请求的按钮.在那种情况下,我可以做一个目标:

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, action: "networkRequest:", forControlEvents: UIControlEvents.TouchDown)

那长长的访问列表让我感到寒意,看起来很糟糕.但是,它似乎仍然遵循MVC.从技术上讲,我们在控制器中执行逻辑,对吗？

但可能还有另一种选择.我们可以给每个视图一个控制器,让每个UIViewController都有一个子控制器用于每个新的子视图.

但是,有些观点是静态的.它们实际上没有任何逻辑,因此它们不一定需要控制器.但是,如果我们要遵循这个约定,我们基本上需要每个视图一个,否则我们会有一个不一致的地方,控制器有一个孙子控制器,但没有子控制器.

所以我们为控制器创建了很多空的棺材.这会构建许多永远不会被使用的死代码,这会导致一些软件腐烂.

那么一个比我更聪明,更聪明的人,这里有什么正确的解决方案？

Answer 1

可能有比我更聪明的 MVC 大师，但我会给它一个破解：

选项 1 - 失败

如果您在 UIView 子类中处理网络请求，那么您肯定会破坏 MVC 模式。根据 Apple 的 MVC 参考：

视图对象是应用程序中用户可以看到的对象。视图对象知道如何绘制自己并且可以响应用户操作。

看起来，视图应该只是处理用户可以看到并与之交互的内容。千万不能走这条路线。

让我们回到 Apple 的视图控制器 MVC 参考：

控制器对象充当一个或多个应用程序的视图对象与其一个或多个模型对象之间的中介。因此，控制器对象是一个管道，视图对象通过它了解模型对象的变化，反之亦然。控制器对象还可以为应用程序执行设置和协调任务，并管理其他对象的生命周期。

请注意文档如何说“一个或多个”，因为视图控制器处理多个视图的逻辑是完全可以接受的。就我个人而言，我会说，如果您的视图只有一个按钮需要网络请求的委托，请继续将父视图的视图控制器设置为委托。

一旦视图的数据处理变得“复杂”，您就应该让视图拥有自己的视图控制器，为了简明起见，我将其定义为“多个操作会掩盖父视图视图控制器的明显目的”。

话虽如此，可以在视图控制器中清楚地标记#pragma mark代码所在位置的确切原因，因此请在此处使用您的判断。

给每个视图一个自己的视图控制器绝对是可行的，但你真的认为有必要吗？每次需要处理单个按钮点击时都创建一个全新的视图控制器，如果应用程序非常庞大，这当然看起来有点矫枉过正。

选择选项#2 并使用你最好的判断。你不会因为破坏 MVC 模式而受到惩罚。最坏的情况是，如果您的视图逻辑变得复杂，您将把您的代码重构为一个新的视图控制器。