复杂 iPad 应用程序中的 MVC 设计模式：一个胖控制器可以接受吗？答案

【问题标题】：MVC design pattern in complex iPad app: is one fat controller acceptable?复杂 iPad 应用程序中的 MVC 设计模式：一个胖控制器可以接受吗？
【发布时间】：2011-06-09 02:31:42
【问题描述】：

我正在构建一个复杂的 iPad 应用程序；将其视为剪贴簿。对于这个问题，让我们考虑一个上面有两张图片的页面。
我的主视图将我的文档数据显示为单个 UIImage；这是因为我需要对它们进行一些全局操作。这是我的DisplayView。
编辑时，我需要用我的两个图像作为子视图实例化一个EditorView；通过这种方式，我可以与单个图像交互（旋转、缩放、移动）。触发编辑时，我隐藏我的DisplayView 并显示我的EditorView。

在 iPhone 应用程序中，我会将每个主视图（即填充屏幕的视图）关联到一个视图控制器。
问题是这里只有一个视图控制器；我考虑过通过模态视图控制器传递EditorView，但这不是一个选项（有一个复杂的布局，其中有一个覆盖所有内容和调色板的掩码；在EditorView 中重建它会创建重复的代码）。

目前EditorView 包含一些逻辑（从模型加载数据，调用一些子视图进行精细编辑，将数据保存回模型）； EditorView 子视图也包含一些逻辑（我操作图像并将它们传递回主视图 EditorView）。我觉得这个逻辑更多地属于控制器。另一方面，我不确定让我唯一的视图控制器这么胖是个好主意。

这种类结构的最佳可可式实现是什么？
随时要求澄清。
干杯。

【问题讨论】：

标签： cocoa model-view-controller ipad ios

【解决方案1】：

在视图周围包裹视图控制器的一些原因：

在需要视图控制器（弹出视图、模式视图、导航栏、标签栏...）的 Apple API 中使用它
因为视图可能会暂时不可见，因此在内存不足的情况下清理它是有意义的。然后，视图控制器会保护需要在这样的卸载-重新加载循环中存活下来的数据。
因为你就是喜欢 MVC 模式

我认为第二个项目符号为您的可编辑内容视图和另一个不可编辑内容视图提供了一个视图控制器。

【讨论】：

我确实意识到 MVC 模式更可取；但正如我所说，我真的无法从主视图控制器转换到EditorViewController，因为视图布局和层次结构非常复杂（顶部有一个巨大的蒙版图像，顶部有一个调色板和一个菜单）。这就是为什么我问我是否遗漏了什么......
Kris，我猜最近的评论中有什么东西，在冒号之后，现在已经消失了；也许是一个链接？
想说：全屏视图的视图控制器（处理调色板以及何时进入编辑模式等）。此控制器需要内容的子视图。它将拥有一个编辑视图控制器，其视图临时用作内容视图。当不处于编辑模式时，此编辑视图控制器要么被释放，要么仅被卸载。

【解决方案2】：

巨大的脂肪控制器很好。

如有必要，只需从中分离一些“纯逻辑部分”并将它们推到其他“帮助类”中。并尽可能广泛地使用类别等技巧。

如果感觉合适，一定要使用 HFC（巨大的脂肪控制器）。

然后，骑上你的工程自行车，把它瘦下来吧！

你绝对不应该因为一件事情太大而回避正确的结构，好的结构，你想要的结构。

只需通过外包概念、对类别发疯等等等等——书中的每一个技巧来缩小这个大问题。

我的信念！

【讨论】：

类别提示非常有意义。我想这就是我要做的，将所有逻辑放入控制器中，并为调色板、编辑器等分解出许多类别。