Cocoa MVC: where is application work logic intende

Question

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? :(

Answer 1

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 PingManager object that centralized this. Alternately, you could have individual HostController objects that managed pinging the server and updated a Host model object. This should not be confused with a HostViewController. 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 UpdateManager for instance).

Generally speaking, what you would most call "application logic" goes in controllers.