我正在学习 Mac OS X 开发,通过阅读不同的文章和 Aaron Hillegass 的书,似乎 MVC 是在基于 Mac 的应用程序中使用的推荐设计模式。
但是,我找不到任何关于我们应该何时引入控制器类/对象以及我们应该使用多少的说明。
所以我的问题是:
在基于 Cocoa 的 Mac OS X 应用程序中,我们通常有一个或多个控制器类吗?如果我们有多个,那么引入新控制器类的标准是什么?控制器类之间如何交互,或者它们不交互并且不需要这种交互?
我正在学习 Mac OS X 开发,通过阅读不同的文章和 Aaron Hillegass 的书,似乎 MVC 是在基于 Mac 的应用程序中使用的推荐设计模式。
但是,我找不到任何关于我们应该何时引入控制器类/对象以及我们应该使用多少的说明。
所以我的问题是:
在基于 Cocoa 的 Mac OS X 应用程序中,我们通常有一个或多个控制器类吗?如果我们有多个,那么引入新控制器类的标准是什么?控制器类之间如何交互,或者它们不交互并且不需要这种交互?
这部分是为了使应用程序易于理解,保持代码井井有条,并且在某种程度上是个人品味的问题。
像 AddressBook.app 这样的简单应用程序可以使用单个控制器层对象。这个对象可以管理用户与人和组的交互。再说一次,它可能有一个 Person 控制器和一个 Group 控制器,每个控制器都将协调它们各自的 UI 片段(Group UI 到 Group 控制器等)和数据容器(组列表和人员列表)之间的交互并且,在查看组时,属于该组的人员列表)。如果您不愿意走到这一步,您可能有一个窗口控制器来存储不特定于组或人的代码。也就是说,管理在 Group 和 Person 模式之间重新配置 UI 的代码可能会进入包含此 UI 的窗口的窗口控制器中。
一个复杂的应用程序可能有许多控制器。它可能有一个用于每个窗口的控制器,这些窗口可能拥有用于专用于应用程序一个方面的自包含控件集的每个实例的控制器。它也可能有控制器来管理非 UI 项目(网络连接/下载、用户会话、附加外围设备的物理状态等)。这真的取决于您的应用程序和设计需求。
应用程序架构是软件开发中一个被低估的方面。在应用程序的整个生命周期中选择和维护一个好的架构有时可能意味着“我们可以在一天内添加此功能”和“我们必须完全重写部分/一半/大部分应用程序才能添加任何类似这个功能的东西”。它既是科学又是艺术,只需要经验(并且要时刻注意你最喜欢的开源项目的架构作为示例)。
需要记住的重要一点是:控制器层是最特定于您的应用程序的层(通常是可重用性最低的部分 - 像 NSArrayController 这样的有目的的可重用控制器无法承受)。这就是使您的应用程序成为您的应用程序的原因。它的模型也可以被其他应用程序及其视图重用,但控制器层是应用程序的“灵魂”。
我希望这有帮助。