UIView & UIViewControllers 设计模式
当 ViewController 在其方法中创建另一个 ViewController 时（比如 viewDidLoad 或 viewWillAppear），这是正确的吗？
就我而言 - 我有一个视图 A，其中包含其他几个视图 - B 和 C，它们本身非常复杂，因此为它们设计了特殊的视图控制器 vcB 和 vcC，并且这些视图控制器是在视图的 vcA 视图控制器内创建的答：
这样可以吗？例如，如果 vcA 将自己设置为 vcB 的委托，该怎么办？这意味着 vcB 将保留 vcA。在这种情况下，为了正确释放所有对象，我们需要在某个地方将 vcB 的委托设置为 nil，但是什么时候这样做最好呢？ viewWillDisappear：，viewDidDisappear：或smth。别的？
我确信这不是唯一出现问题的情况，所以我正在寻求您的意见，如何正确设计视图控制器之间的此类交互。
Is that correct, when ViewController creates another ViewController inside its' methods (let's say viewDidLoad or viewWillAppear)?
In my case - I have a view A, that contains several other views - B and C, which are quite complex by themselves, so special view controllers vcB and vcC were designed for them and these view controllers are created inside vcA view controller of view A.
Is this OK? What if, for example, vcA sets itself as a delegate for vcB. Which means, that vcB will retain vcA. In this case, to correctly release all objects, we need somewhere set vcB's delegate to nil, but what is the good moment to do this? viewWillDisappear:, viewDidDisappear: or smth. else?
I'm sure it's not the only case, where problems are rise up, so I'm looking for your opinions how to correctly design these kind of interactions between view controllers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我目睹了一种教条式的坚持，即一次只能运行一个视图控制器。就我自己而言，如果可以简化整体设计（降低复杂性）并使设计管理更容易，我倾向于同时使用多个视图控制器。正如您可以在最近的回复中读到的那样，我发布，在我看来，Apple 已经朝着相同的方向发展，提供了对自定义内容视图控制器的支持，允许您同时操作多个视图控制器。
乔纳·威廉姆斯 (Jonah Williams) 的博客值得一读，只是为了了解您可能需要处理的问题。但坦率地说，我没有遇到任何与他的建议相矛盾的问题。 （那篇文章大约有一年了。）
视图控制器的一个关键部分是保存它所管理的视图的委托方法。视图实际上并不关心哪个对象充当其委托。因此，如果您想要一个与单 VC 观点更加和谐的设计，您可以将委托方法放入子类 NSObject 中，而不将其称为视图控制器。不过，您很可能必须创建 UIViewController 中已有的一些方法。但这样你就不必将其称为视图控制器。我，我只是子类化 UIViewCcontroller。
I have witnessed a dogmatic adherence to the idea that only one view controller should be operating at one time. As for myself, I lean toward using more than one view controller at the same time if it simplifies the overall design (reduces complexity) and makes design management easier. As you can read in a recent response that I posted, it appears to me that Apple has moved in the same direction by providing support for custom content view controllers that allow you to operate multiple view controllers at the same time.
The blog by Jonah Williams is worth reading, just to be aware of what you might have to deal with. But Frankly, I haven't had any problem contradicting his advice. (That post is about a year old.)
A key roll of the view controller is to hold the delegate methods of the view it is managing. The view really doesn't care what object is acting as its delegate. So if you wanted a design that is more harmonious with the single-VC point-of-view, you can put the delegate methods into a subclassed NSObject and not call it a view controller. You will most likely have to create some of the methods that a UIViewController already has in it though. But then you don't have to call it a view controller. Me, I just subclass a UIViewCcontroller.
通常，您不希望为另一个控制器的子视图使用单独的视图控制器。这不是视图控制器设计的工作方式。
苹果的导航和标签栏控制器可以做到这一点，但它们非常复杂且非标准（这大概就是为什么你不允许对它们进行子类化的原因。）
Generally, you don't want separate view controllers for subviews of another controller. That's not the way view controllers were designed to work.
Apple's navigation and tab bar controllers do this but they're hideously complicated and non-standard (which is presumably why you're not allowed to subclass them.)