Cocoa MVC：应用程序工作逻辑应该放在哪里？
我在苹果开发网站上看到的所有 Cocoa MVC 文档都对“数据”等实体进行操作：模型保存“数据”，控制器显示“数据”，视图确保数据来回传输。但是，只有当您创建像“日历”或“联系人”这样的数据库访问应用程序时，这种方法才有效:(。
但是其他应用程序类型在哪里？例如，让我们采用一个创建单独线程 ping 的 GUI“ping”应用程序远程计算机并绘制一个很好的 ping 响应时间图表。 Cocoa MVC 中的实际 ping 代码在哪里？是在模型内部还是在 MVC 外部？
下一个示例是“锁定屏幕”实用程序，它显示用于配置锁定 OSX 的快捷方式。屏幕实际的应用程序逻辑是快捷方式处理代码和检查该快捷方式是否已在模型中、在控制器中或在 MVC 外部的
代码 ？是在模型、控制器还是外部 MVC 中？
我很好奇，Apple 是否有任何官方信息/指南来强调上述问题？或者对于 Apple 来说，所有应用程序都是数据库前端？
All Cocoa MVC documentation I see on the apple dev site operates on entities like "data": model holds "data", controller displays "data", view ensures that data and transferred forth and back. But such approach is good only if you create a database access application like "calendar" or "contacts" :(.
But where are some other application types? For example, let's take a GUI "ping" application that creates a separate thread, pings remote computer and draws a nice graph of ping response times. Where actual ping code goes in Cocoa MVC? Is it inside model, controller or outside MVC?
Next example is "lock screen" utility that displays GUI to configure the shortcut that will lock OSX screen and will handle this shortcut. Actual app logic is the shortcut handle code and the code that will check that shortcut is not already used. Is it in model, in controller or outside MVC?
Parts of application like "check new version on startup" - is it inside model, controller or outside MVC?
I'm curious, are there any official info / guides from Apple that highlight mentioned questions? Or for Apple all applications are database frontends? :(
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
MVC 架构适用于各种应用程序类型，而不仅仅是以数据为中心的应用程序。例如：
PingManager对象。或者，您可以拥有单独的HostController对象来管理 ping 服务器并更新Host模型对象。这不应该与 HostViewController 混淆。控制器可以协调模型对象而不需要视图对象。处理程序和快捷方式系统之间的交互将是控制器功能。
版本启动检查通常是应用程序控制器函数，尽管它可以是其自己的控制器对象（例如
UpdateManager）。一般来说，您最常所说的“应用程序逻辑”位于控制器中。
The MVC architecture works for a wide variety of application types, not just data-centric applications. For example:
A GUI ping application should have a model that keeps track of the list of hosts, their current status, and their response times. The act of "pinging" itself would generally be called a controller function. I would likely create a
PingManagerobject that centralized this. Alternately, you could have individualHostControllerobjects that managed pinging the server and updated aHostmodel object. This should not be confused with aHostViewController. Controllers can coordinate model objects without requiring view objects.Handling the interaction between the program and the shortcut system would be a controller function.
Version startup checks would generally be an application controller function, though it could be its own controller object (an
UpdateManagerfor instance).Generally speaking, what you would most call "application logic" goes in controllers.