使用 Cocoa-Touch，但这是一个普遍的问题。
视图是否可以保留对其视图控制器的引用并处理数据？我最近遇到了一个在整个应用程序中执行此操作的代码库 - 例如，有一个表格视图控制器，它的单元格对视图控制器的引用很弱（因此没有保留周期）。单元格通过
呈现新的视图控制器[self.parentVC presentViewController.....];
并以类似的方式将其关闭。此外，它们还处理数据/网络操作的变化。
在我看到这个之前，我习惯于为每个单元创建协议并通过它们与父视图控制器对话。使用直接引用视图控制器的方式摆脱所有协议。
对我来说，这似乎很糟糕，但不确定它是否普遍。
【问题讨论】：
标签： ios objective-c cocoa-touch model-view-controller uiviewcontroller
嗯，......这并不罕见，也不是很好的风格。我自己这样做了，几乎迷路了。每当需要时，我都会尝试采用委托模式。这意味着，是的，我确实保留了对恰好是视图控制器的委托的引用。委托对象确实实现了一个协议，在该协议中我总结了我将要调用的所有视图控制器（委托）的方法。
在这种情况下和您的示例中，单元格将通过调用方法通知视图控制器发生的事情，然后视图控制器将调用下一个要调用的视图控制器。
通过这样做，我实现了同样的目标，但有点坚持 MVC 模式，因此始终知道在哪里寻找什么样的功能 - 即使在一年左右的时间里。
【讨论】：
即将到来的答案是关于 Apple 处理模型视图控制器的方式，这与其他 SDK（例如 Qt）完全不同。
这绝对是不好的做法。可以归结为一个问题，如果您认为这是一个好主意，那么为什么 Apple 还没有在 UIView 类中添加该引用？
如果你看Apple uses the model view controller，模型就很清楚了：
视图与控制器通信以发出状态更改的信号，控制器在需要时更新模型并相应地更新视图。您永远不会在其中找到用于更新堆栈控制器的 Apple 文档或示例。
如果UIView 子类开始持有对持有它的控制器的引用（即使它是弱引用），您正在删除视图对其控制器的抽象（引用是另一种方式），并且因此强烈鼓励那些使用相同代码的人的不良做法。
什么会阻止其他开发人员这次在视图附加到的“模型”上添加引用？
现在我并不是说这会将您的代码变成意大利面条式代码（您仍然可以用它制作一个像样的应用程序），我是说这真的是（真的！）不好的做法。
希望这已经足够清楚了。
【讨论】：
我认为可能两者兼而有之：非常糟糕和普遍。
视图应该是通用的，它们不需要知道关于它们的控制器的任何细节。通信应限于委托（协议）、数据源（协议）或目标操作。
【讨论】：