使用自定义视图控制器来管理同一视图层次结构的不同部分
视图控制器编程指南说明了有关视图控制器的用法：
每个自定义视图控制器对象 create 负责管理所有 单个视图中的视图数 等级制度。在 iPhone 应用程序中， 视图层次结构中的视图 传统上覆盖整个屏幕， 但在 iPad 应用程序中，它们可能 仅覆盖屏幕的一部分。 之间的一一对应关系 视图控制器及其中的视图 视图层次结构是关键设计 考虑。 您不应该使用 多个自定义视图控制器 管理同一内容的不同部分 查看层次结构。同样，你 不应使用单个自定义视图 控制器对象来管理多个 屏幕上有价值的内容。
我知道，如果我们使用多个自定义视图控制器来控制视图的各个部分（即视图控制器来管理主视图的子视图，而主视图又由视图控制器管理），则默认方法（如：
didReceiveMemoryWarnings
viewWillAppear
viewWillDisappear
viewDidUnload
等）将不会称为。
除此之外，还有其他充分的理由说明我们不应该使用多个视图控制器来管理视图的各个子视图吗？
该文档还提供了一种替代解决方案，其内容如下：
注意：如果要分割视图 层次结构分为多个子区域和 分别管理每一个，使用 通用控制器对象（自定义 NSObject 的后代对象） 而不是视图控制器对象 管理各个分区。然后使用单个 视图控制器对象来管理 通用控制器对象。
但没有提及为什么不应该首选多个视图控制器。我的问题是：
为什么我们不应该选择这种方式？
我很担心，因为我更喜欢使用 UIViewController 的子类来管理我的视图，因为我每次都从笔尖加载它们，并且我为每个视图控制器隔离笔尖。满足项目后期阶段的变化变得很容易。这是错误的吗？我是否必须改变我的编程风格，或者我是否可以继续采用这种方法？
谢谢，
拉吉
The View controller programming guide states this regarding view controller's usage:
Each custom view controller object you
create is responsible for managing all
of the views in a single view
hierarchy. In iPhone applications, the
views in a view hierarchy
traditionally cover the entire screen,
but in iPad applications they may
cover only a portion of the screen.
The one-to-one correspondence between
a view controller and the views in its
view hierarchy is the key design
consideration. You should not use
multiple custom view controllers to
manage different portions of the same
view hierarchy. Similarly, you
should not use a single custom view
controller object to manage multiple
screens worth of content.
I understand that if we use multiple custom view controller's to control the parts of a view (i.e. a view controller to manage subViews of a main view which in turn is managed by a view controller) the default methods like:
didReceiveMemoryWarnings
viewWillAppear
viewWillDisappear
viewDidUnload
etc. etc. will not be called.
Apart from this, is there any other solid reason why we should not be using multiple view controllers to manage the respective subviews of a view?
The documentation also provide an alternative solution which reads as:
Note: If you want to divide a view
hierarchy into multiple subareas and
manage each one separately, use
generic controller objects (custom
objects descending from NSObject)
instead of view controller objects to
manage each subarea. Then use a single
view controller object to manage the
generic controller objects.
But there is no mention as to why multiple view controllers should not be preferred. My question is:
Why should not we prefer it this way?
I am concerned because I prefer using UIViewController's subclass to manage my views since I load them from nib each time and I segregate nibs for each view controllers. It becomes easy to cater the changes in later stages of the project. Is this wrong? Should I necessarily change my programming style, or is it ok if I go ahead with this approach?
Thanks,
Raj
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好吧，我会说“只要它有效”，你就可以继续这样做！
但为了让事情变得“干净”，我会使用我自己的物品。
由于 ViewController 在设计时考虑了其他通用功能（例如使用导航控制器和选项卡栏控制器），这使得它对于简单的使用来说有点“重”，就像您一样。
另外，就像您提到的，只有当 viewController 的视图添加到主窗口时才会调用某些事件。
您不能通过 Interface Builder 使用您自己的对象吗？如果您创建一个（或多个）UIView IBOutlet，它的工作原理应该是相同的。
Well, I'd say "as long as it works", you can keep on doing like you do !
But to keep things "cleaner", I'd use my own objects.
Since ViewControllers are designed with other general features in mind (like working with navigation controllers and tab bar controllers), which makes it a bit "heavy" for a simple usage, like you do.
Plus, like you mentioned, some events are only called when the viewController's view is added to the main window.
Can't you use your own objects with Interface Builder ? If you create one (or several) UIView IBOutlet(s), it should work the same.
我有一个应用程序在单个屏幕上使用两个 UIViewController。子级是一个 UITableViewController。我不依赖子级的任何 UIViewController 行为——仅依赖 UITableViewController 方法。这很方便，因为在其他情况下子 UITableViewController 确实管理整个屏幕。在这种情况下，它确实使用 UIViewController 方法。设计有问题？或许。现在已经运行两年了，效果很好。但我不确定我是否会推荐该模式。
I have an app that does use two UIViewControllers on a single screen. The child is a UITableViewController. I don't rely on any of the UIViewController behavior of the child -- only the UITableViewController methods. This is convenient because there are other cases where the child UITableViewController does manage the whole screen. And in that case, it does use the UIViewController methods. Questionable design? Maybe. It has worked fine for two years now. But I'm not sure I would recommend the pattern.