何时为自定义子视图子类化 UIViewController？
我见过自定义子视图作为 UIViewController 子类实现，但也许可以作为 UIView 子类实现。
我什么时候应该子类化 UIViewController 而不是 UIView 作为子视图？子类化 UIViewController 有什么缺点吗？
I've seen custom subviews implemented as an UIViewController subclass, but that maybe could have been implemented as an UIView subclass.
When should I subclass UIViewController instead of UIView for a subview? Are there any drawbacks to subclassing UIViewController?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
就我个人而言，当我需要一些重要的逻辑来继续时，我会使用 UIViewController 子类来完成。另外，如果我正在寻找从 UIViewController 获得的一些行为，例如以模态方式或在导航控制器中呈现它。
如果您正在做一些相当简单或轻量级的事情，
UIView子类通常就足够了。我似乎在制作自定义按钮和表格视图单元格时最常使用它们。根据我的经验，我发现自己使用的
UIViewController子类比UIView子类多，但这可能不是最好的，碰巧我觉得使用视图更舒服控制器而不是直接视图。Personally, when I need some significant logic to go on, I do it with a
UIViewControllersubclass. Also, if I am looking for some of the behavior that you get fromUIViewControllere.g. presenting it modally or in a navigation controller.If you are doing something fairly simple or lightweight, a
UIViewsubclass is usually enough. I seem to have used them most often when making custom buttons and table view cells.In my experience I have found myself using more
UIViewControllersubclasses thanUIViewsubclasses, but this might not be the best, it just so happens that I feel a bit more comfortable using view controllers rather than straight-up views.看看苹果在 上所说的内容控制器对象和MVC 设计模式
在 iOS 中，控制器通常被期望至少扮演以下角色之一：
协调控制器提供应用程序特定的逻辑。他们响应委托消息、通知和 IBAction。协调控制器还建立其他对象之间的连接，并经常管理这些对象的创建和销毁。
视图控制器，特别是 UIViewController，管理一个“屏幕”内容的显示并触发到下一个“屏幕”的转换。它们响应内存警告和旋转事件。
OS X 中存在中介控制器，但它们的角色通常由 iOS 中的视图控制器承担。它们充当视图和模型之间的中介；当视图接收输入时更新模型，当模型更改时更新视图。
如果您正在实现的行为符合这些类别之一，您可能需要创建一个控制器对象。如果您的逻辑只关心数据的显示（并且可能响应用户输入），那么它可能属于视图层。如果您的逻辑与数据本身有关，那么它可能属于模型。
如果您在任何这些层中都找不到适合您的逻辑的方法，那么您可能应该将其建模为属于不同层中不同对象的不同职责的组合。即从中介视图控制器请求数据显示的视图。
Take a look at what Apple has to say on Controller Objects and the MVC design pattern
In iOS controller are generally expected to fill at least one the following roles:
Coordinating controllers provide application specific logic. They respond to delegate messages, notifications, and IBActions. Coordinating controllers also setup connections between other objects and often manage the creation and destruction of those objects.
View controllers, specifically UIViewControllers, manage the display of one "screen" worth of content and trigger transitions to the next "screen". They respond to memory warnings and rotation events.
Mediating controllers exist in OS X but their role is usually filled by view controllers in iOS. They act as an intermediary between views and models; updating models when views receive input and updating views when models change.
If the behavior you are implementing fits into one of these categories you probably want to create a controller object. If your logic is only concerned with the display of data (and possibly responding to user input) then perhaps it belongs in the view layer. If your logic is about the data itself then it probably belongs in the model.
If you can't find a good fit for your logic in any of those layers then you probably should model it differently as a combination of different responsibilities which belong on different objects in different layers. ie a view which requests data to display from a mediating view controller.
如果您要在“视图”中使用 AdBannerView，您还需要对 UIViewController 进行子类化。 AdBannerView 需要 UIViewController 才能工作。
You would also subclass the UIViewController if you're going to use an AdBannerView in your "view". AdBannerView needs a UIViewController to be able to work.
我遵循的经验法则是，如果您正在进行自定义绘图，请子类化 UIView。否则，子类化 UIViewController。
The thumb rule I follow is, If you are doing custom drawing, subclass UIView. Otherwise, subclass the UIViewController.