|
当我在考虑 Cocoa 中 MVC 的所有化身时，我想我可以为应用程序中的每个 View 创建一个自定义类，并用数据源和委托(delegate)填充它——这些东西主要是为 Controller 考虑的。
通过这种方式，我可以砍掉一些代码，并将它们放在单独的文件中——一个 View 一个类——连同它们的数据源和委托(delegate)，而不是臭名昭著的 Massive-View-Controller。
这是个好主意，还是有什么缺点？
Best Answer-推荐答案
恐怕您的想法听起来会导致您最终得到一堆臃肿的 View ，而不是一堆臃肿的 Controller 。
我的建议是考虑 Single Responsibility Principle : 一个实体应该只有一个目的或功能。 View 的功能是什么？
它是屏幕区域的代码表示。这意味着它需要做两件事:绘制到它的区域并注册与该区域的交互。对这两个子任务来说不是绝对必要的任何东西都不应该在 View 类中。
这就是“哑 View ”的概念。它没有逻辑，没有决策可做。它只是得到一些数据来渲染。当它被点击或点击时，它不知道输入代表什么，或者试图弄清楚如何处理它。它只知道交互的类型并告诉另一个对象。
另一个对象是 View 的 Controller 。 View Controller 的职责是在 View 和系统的其余部分之间进行调解。它为 View 提供数据。它还接受来自 View 的有关输入的消息，然后根据这些消息的结果重新配置 View 。
但是， View Controller 不一定需要自己计算结果。这通常是 View Controller 开始陷入“巨大”麻烦的地方。 View Controller 应该选择另一个对象来帮助它获取交互产生的新值。
另一个对象的一种可能性是 View 模型，在 MVVM structure 中。 . View 模型是 View 原始数据的以显示为中心的表示。它将模型中的信息转换为 View 需要的任何格式，并重新转换或更新数据以响应来自 View Controller 的输入。
另一个想法是使用 VIPER 更精细地划分责任。安排。这里数据的格式化由“Presenter”处理，数据的转换是“Interactor”的工作。
在这里进入建筑宇航员领域是可能的；如果 View 的需求本质上非常简单，那么盲目地应用复杂的结构可能会咬你一口。但即使您选择不正式应用这些替代模式之一， View Controller 也需要其他对象。您将需要具有其他特定作业的“ Controller ”，从 View Controller 获取消息并将数据传回。
重要的是要牢记我提到的最初想法:努力让每种类型做一件事并做好。这将使您的类(class)保持专注；易于阅读、理解和思考；并且可测试。
关于ios - 在自定义 View 下确定 Controller 代码的范围是一个好的 cocoa 设计模式吗？，我们在Stack Overflow上找到一个类似的问题：
https://stackoverflow.com/questions/41782271/
| 
