ios - MVC 模型 - Controller 应该直接访问 View 的控件吗？

Question

我正在学习 iOS 开发，我在教程和书籍中发现 Controller 层通常可以直接访问 View 的控件(文本字段、标签等)。让我们考虑这样一个例子:

假设，该 View 有一个名为 lblResult 的标签和一个名为 txtDataToAnalyze 的文本字段。比起在 Controller 界面中，我们有这样的东西:

@property (nonatomic, retain) IBOutlet UILabel* lblResult;
@property (nonatomic, retain) IBOutlet UITextField* txtDataToAnalyze;

以及实现文件中的一些@synthesize语句。

我有一些 JavaSwing 开发经验，其中大多数人认为我是在没有任何 GUI 构建器的情况下手动编写的，而我通常在 MVC 中所做的是通过 getter/setter 访问 View 的控件。例如:void setResult(String resString); 或 String getDataToAnalyze();。这样， Controller 只知道 View 中显示了什么信息，而不知道它们是如何显示的。我认为它更灵活(以后更改 View 层更容易)。

我知道 iOS 有一些特定的规则，引入了 XIB/NIB 文件等，所以对于 iPhone/iPad 开发，我的疑虑可能完全没用。但我打算为 iOS 编写一些更严肃的应用程序(实际上是从 Java Swing 中“重写”它)，这就是为什么我想问你:

你认为，我应该改变我的思维方式并习惯这种新的(对我而言)方法(xib 文件、使用拖放创建 GUI 和向 Controller 提供有关数据应如何在 View 中显示的信息) ??刚入手iOS的你有没有类似的疑惑？

Answer 1

简答:

是的，我认为您绝对应该花一点时间习惯使用 Interface Builder (IB) 制作 NIB 和 Storyboard，并让 IB 创建 IBOutlet 和 IBAction 为您提供需要交互的那些控件的引用。一旦您精通它，您将对您生成易于维护的代码的效率印象深刻。不要太快解雇 IB。

就让 Controller 直接与 IBOutlet 和 IBAction 引用交互而言，这是简单用户界面的常见做法。如果您有一些真实世界的示例，请发布带有屏幕快照的新问题，我们可以提供更多实用指导。

长答案:

1. 您的问题的部分原因似乎是看到 View Controller 与 View 控件进行详细交互时的忧虑。问题是，如果你想将你的 Controller 与 View 的一些实现细节隔离开来，那么继续对 View 进行子类化并将 View 特定的东西放在那里。 IB 可以与 View Controller 子类以及 View 子类进行交互。因此，您可以愉快地使用 IB，并且仍然将您的 View Controller 与其中一些实现细节隔离开来。

   就个人而言，我只在 View 达到某个主观复杂性阈值时才对 UIView 进行子类化(例如，对我来说，该阈值是当我发现自己在做一些复杂的动画时，例如使用 CADisplayLink；复杂的手势识别器等)。我还将那些作为它们自己的逻辑实体的 subview 子类化(例如 UITableViewCell 或 UICollectionViewCell)。但是对于我与我的模型交互以设置控件的属性、与文本字段交互等的简单 View ，我认为将它放在 View Controller 中就可以了。话虽如此，如果我的 Controller 中有很多特定于 View 的代码，而这些代码与我的模型与我的 View 的集成无关，那么就开始子类化 UIView 并移动仅 View 将代码写入其中。

2. 您的问题中隐含了以编程方式构建 View 而不是使用 NIB/ Storyboard的概念。在我看来，使用 Interface Builder (IB) 构建 UI 更易于开发和维护。做一个以编程方式构建 View 的测试项目可能有一些教学值(value)，因此您真正了解发生了什么，但在那之后，我认为您会发现自己很快就会被 Storyboard 所吸引。当您开始做超出标准 IB 控件功能的事情(例如复杂的自定义容器 View 等)时，您将有很多机会编写自己的非 IB 代码。肯定有人更喜欢以编程方式开发 View ，但我认为您无法超越 IB 生成的 UI 的开发速度和易维护性。