When we’re first learning Cocoa (or Java, or Qt, or any other application framework), one of the early things we address is the Model-View-Controller design pattern. The Model-View-Controller (MVC) design pattern prescribes that a well-designed application will separate data-specific code (the model layer) from user-interface-specific code (the view layer), and that the two layers will communicate with each other by way of the controller layer. From its inception, Cocoa has provided excellent support for model and view layer objects. Read the rest of the article at MacDevCenter by Michael Beam.
The Cocoa Controller Layer
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I just wish the controller classes had been implemented earlier! I’ve got two very complex Cocoa apps I’m working on that I wrote my own controller classes for, it would probably be more work to rewrite them at this point. But I’m looking forward to using the controller classes in any new applications.
I’ve been using the NSController subclasses extensively. Great stuff.
Hate to say “me too” but, “me too”. I’ve been working on a ludicrously complicated simulation framework in cocoa, c++, opengl and more — I’ve had to write a ton of backward-forward synchronization code to keep the GUI reflecting the internal state and frankly it’s a pain — mainly because the actual model for my system is 99% C++. So I end up having many “bridging” cocoa ( objective-c++ ) classes so my app controller ( and other sub-controllers ) can maintain state with the underlying system.
If my app were 100% cocoa, I’d happily dive in, but since the new controller system relies heavily on Cocoa’s beautiful RTTI and other magic in NSObject I don’t think I could make any use of it whatsoever.
It looks promising, nontheless. And if I can, I’ll definitely use it in the future. This tutorial is needed, btw, since Apple’s documentation, while excellent, is still a little opaque. I’ve read the docs on the new Controller bindings and still have a little trouble grokking it.
I assume your using C++ because your binding to some pre-existing codebase and C++ makes that easier. Just curious.
In any case, I think you probably could have made use of it. There’s a lot you can do. For instance, you can subclass NSController or any of its subclasses to create custom controllers, if necessary. And they can do whatever you wish. (Mine is doing my laundry right now.)
But I understand that when you’re deep into a project, refactoring can be a real bitch.
http://cocoa.mamasam.com/COCOADEV/2003/10/2/75193.php
I read “The Problems With NSController” with interest, and yet I’ve still found NSController and its subclasses to be of great practical value. They’ve saved me a lot of time and trouble.
I’ve created a subclass of NSArrayController that talks to a PostgreSQL (or any) database, and it works handily and automagically. I plan to turn it into a framework. It does use delegation, and in fact most of its database-specific state is stored in the delegate. It needs a little work to be truly generic.
There’s no question that EOF is a better way to go, but at the moment it is not an option for me. (My understanding is that EOF is not included with OS X because it was reimplemented in Java, which is unfortunate, because I like ObjC a lot better.)
http://www.bignerdranch.com/Resources/nscontroller.html
Scroll to the end of the article to see a summary. I think he reacted a little prematurely, and his reaction has more to do with his history developing EOF and being annoyed at it being left in the java space. Still, it’s an interesting read as he notes this technology still has a few rough edges and where it doesn’t live up to Enterprise Web Objects. Shame they discontinued that really, I’m not sure about the politics of it all and why they did.
I do find it encouraging that NSArrayController replaces almost perfectly some of the controller classes in an app I’m writing (this seems to be the case for a lot of people). That would imply that they’ve chosen a good class to add to their basic types. The bindings stuff is pretty neat too – saves a lot of time on preferences for example. If used with care I don’t think it breaks encapsulation at all – you are allowed to override the accessor methods, and it goes through them by preference.
Before bindings it’d be normal to have a whole bunch of refs to interface elements in your controller object, so you could fill them in when the data changed. With bindings the interface elements can query your controller directly, so no need for all that glue code.
All credit to Aaron for correcting what he said publicly but then perhaps he shouldn’t have flamed to start with! Of all his criticisms, I think the one about the lack of built in database functionality is the most telling – this is something which would win Apple, and Objective-C, a bigger following with business users building database front-ends. There are other options, but it wouldn’t hurt to have something built in.
Funny you mention Postgres, I basically wrote my own framework around libpq, even thought about releasing it once I know for sure it’s solid. But I will at least put together a test app using NSArrayController and see how it goes. And I never understood Apple leaving out EOF, would have made a lot of developers happy if they had kept it…
You know, you could also use the GNUstep Database Layer (GDL2), a clone of EOF 4.5, on MacOS X …