MVC in a Cocoa document-based application

Question

I'm going through a refactoring and reorganization of my application at the moment. I've realized that some of the separation between models and views, and their controllers has diminished and I wish to do some cleaning up.

I have several key classes used in my app: NSPersistentDocument, NSWindowController, and a model class.

The NSPersistentDocument class acts as a "model-controller"; it owns an instance of the model class, and manages all interactions with the model.

The NSWindowController class acts as a "view-controller"; it owns the main window, and manages interactions of the views within the main window. This class is also the File's Owner for the nib file in which the Window is defined.

The problem I see here is that I don't have a real "controller". My current design forces the model-controller and view-controller to know about each other. There is no meditating object between the two, and due to this, my model and view are not clearly separated, which makes supporting multiple views or models a problem.

I would like to move functionality from both of my existing controllers into a new "controller" class which would act as a controller between the model-controller and view-controller. In the end, this is still just the MVC design pattern, with just a little more structure.

However, I am having difficulty figuring out how this would fit into Cocoa's document-based app architecture.

The biggest question I have is where and how would this new controller object be created? How does this fit into Cocoa's architecture? Am I fighting against Cocoa's architecture, and is there a better way to do this?

Thanks.

Answer 1

Sounds like you need to pick up a copy of Cocoa Design Patterns, answers these questions and then some.

Chapter 2 deals with the MVC pattern using an ArrayController as the model controller (rather than the persistent document model-controller you are using).

Answer 2

Great instincts on having a "model controller" and a "view controller". That's a very good mental taxonomy for how the M's and the V's usually hang together. But you can still have the pure "C" in the MVC to tie the whole operation together, as you note.

If you're talking about one controller, for the app: Think of the (big-C) Controller as the thing that grows out of your app's main() function-- in older Cocoa tutorials this object is often called AppController. It might be the delegate of UIApplication, or not, but if it's not, you should consider creating such a master controller in the applicationDidFinishLaunching: method of the app delegate in your project. That AppController can then set up (and own) the model objects and set up (and own) the root view controller, from which your UI springs.

If you're talking about some mediating component that there are multiple instances of, one for each model/view "pair" in a document architecture, then just make something like that up also. DocumentController is the kind of name you want, although Cocoa has one of those already that may or may not reflect the kind of functionality you need. "DocumentManager" is another candidate name.