我正在学习iOS开发的东西，我在教程和书籍中发现的是控制器层通常可以直接访问View的控件（文本字段，标签等）。让我们考虑这样一个例子：
假设该视图有一个名为lblResult的标签和一个名为txtDataToAnalyze的文本字段。比在控制器界面，我们有这样的东西：
@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();。这样，控制器只知道在视图中显示哪些信息，而不是 显示的方式。我认为它更灵活（以后更容易更改视图层）。
我知道iOS有一些特定的规则，已经引入了XIB / NIB文件等，所以在iPhone / iPad开发的情况下，我的怀疑可能完全没用。但是我要为iOS写一些更严肃的应用程序（实际上是从Java Swing“重写”它），这就是我想问你的原因：
你认为，我应该改变我的思维方式并习惯于那种新的（对我来说）方法（xib文件，使用拖放操作创建GUI，以及为控制器提供有关如何显示数据的信息在视图中）??从iOS开始，你有类似的疑虑吗？
答案 0 :(得分：4)
简短回答：
是的，我认为你应该花一点时间习惯使用Interface Builder（IB）制作NIB和故事板，让IB为你创建IBOutlet和IBAction个参考文献您需要与之交互的控件。一旦你精通它，你就会对生成易于维护的代码的效率印象深刻。不要太快解雇IB。
在让控制器直接与IBOutlet和IBAction引用交互方面，这是简单用户界面的常见做法。如果您有一些真实的例子，请发布一个带有屏幕快照的新问题，我们可以提供更实用的指导。
答案很长：
您的部分问题似乎是由于看到视图控制器正在与视图的控件进行详细交互而感到担忧。问题是，如果您想要将控制器与视图的某些实现细节隔离开来，那么继续进行视图的子类化并将视图特定的东西放在那里。 IB可以与视图控制器子类以及视图子类进行交互。因此，您可以愉快地使用IB，并且仍然可以将视图控制器与其中一些实现细节隔离开来。
就个人而言，当视图达到一些主观复杂性阈值时，我只对UIView进行子类化（例如，对我而言，该阈值是当我发现自己做一些复杂的动画时，例如使用CADisplayLink;复杂的手势识别器等）。我还将那些属于他们自己的逻辑实体的子视图子类化（例如UITableViewCell或UICollectionViewCell）。但是对于我正在与我的模型进行交互以设置控件属性，与文本字段交互等的简单视图，我认为将它放在视图控制器中就可以了。话虽如此，如果我的控制器中有很多特定于视图的代码与我的模型与我的视图的集成无关，那么就开始子类化UIView并将仅查看代码转换为
您的问题隐含的是以编程方式构建视图而非使用NIB /故事板的概念。在我看来，使用Interface Builder（IB）来构建UI更容易开发和维护。做一个测试项目可能会有一些教学价值，你可以通过编程方式构建你的视图，所以你真的了解发生了什么，但在那之后，我认为你会发现自己很快就会被故事板所吸引。当你开始做超出标准IB控件功能的事情时（例如复杂的自定义容器视图等），你将有很多机会编写自己的非IB代码。肯定有人喜欢以编程方式开发视图，但我认为你不能超过IB生成的UI的开发速度和易维护性。
答案 1 :(得分：1)
我很一般，控制器不知道视图，但视图知道控制器。
这帮四本书说：
“MVC还允许您更改视图响应用户输入的方式而不更改其可视化表示。例如，您可能希望更改其响应键盘的方式，或者让它使用弹出菜单而不是命令键.MVC将响应机制封装在Controller对象中。有一个控制器的类层次结构，可以很容易地创建一个新控制器作为现有控制器的变体。
视图使用Controller子类的实例来实现特定的响应策略;要实现不同的策略，只需用不同类型的控制器替换实例。甚至可以在运行时更改视图的控制器，以使视图更改其响应用户输入的方式。例如，可以禁用视图，以便仅通过为其提供忽略输入事件的控制器来接受输入。
视图 - 控制器关系是策略（315）设计模式的示例。策略是表示算法的对象。当您想要静态或动态替换算法时，当您有很多算法变体时，或者当算法具有您想要封装的复杂数据结构时，它非常有用。“