这是一个关于UIViewController课程的开放式问题，以及他们在iOS应用中的正确角色。
我最近阅读this article，我部分同意作者。显而易见的是，与您的视图和模型相关的每一点逻辑都不会最终被转储到UIViewController中，但是单独构建所有视图并使用委托方法访问操作似乎有点极端
我很好奇哪种设计在应用程序的内存和性能方面最有效（在处理移动应用程序时这显然是一个重要的考虑因素）？正如该帖子的作者所指出的那样，苹果似乎没有强烈反对在UIViewController中提出逻辑。
最终，我想知道正确的做事方式。所以问题是，视图和与之相关的任何逻辑是否应该完全从VC中分离出来？我真的应该使用代表与UIViewController进行沟通吗？
答案 0 :(得分：6)
视觉控制器本质上并不是邪恶的，尽管它们通常会变成单一的混乱，因为它们非常便于扩展。
...单独构建所有视图并使用委托方法访问操作似乎有点极端。
将其视为将程序分解为更小的单元，无论可能是什么。在每种情况下对UIView进行子类化并不是最佳解决方案（作为一个示例）。
每个开发人员的容差都有所不同，它因程序/案例而异，但很容易识别并消除重复的代码，并将程序分解为更小的单位。
我认为大多数课程都是：
当然，会有例外。
我很好奇哪种设计在应用程序的内存和性能方面最有效（在处理移动应用程序时这显然是一个重要的考虑因素）？
通过编写更多可重用的程序，您将获得更多收益。为这些可重复使用的设计投入更多时间和精力，减少重复代码，并专注于质量。将性能和内存写入您关注的设计中。一般来说，与可怕的新编写的，测试不良的单片风险投资相比，这将带来巨大的胜利。
最终，我想知道正确的做事方式。所以问题是，视图和与之相关的任何逻辑是否应该完全与VC分离？我真的应该使用委托与UIViewController进行通信吗？
过度简化：不，如果您消除冗余代码，在适用的情况下专注于可重用性，并确保您的单元/类保持低复杂性，则不必走那么远。当然，无论是VC还是其他类型，都要在问题成长为单片类之前解决这些问题。
答案 1 :(得分：2)
一年前我也读过这篇文章，当时我正在寻找比你到处看到的更好的iOS编码实践（在视图控制器中倾倒所有类型的垃圾......）。我同意其观点，但不幸的是它没有提供任何解决方案。 经过一年相当大的iOS应用程序，复杂的数据模型，远程服务和高度非线性导航，我的经验归结为以下几点：