The Problems with NSController

FROM : Aaron Hillegass
DATE : Sun Oct 26 15:42:15 2003

While working on the second edition of "Cocoa Programming for Mac OS
X," I have spent a good chunk of time working with NSController and the
bindings mechanism. And I have bad news: they are poorly designed and
poorly implemented. I sincerely hope that this technique is deprecated
because it will become embarrassment for Apple and the entire Cocoa
community.

History first: NeXT used to compete in the client-server market against
products like PowerBuilder. Minimizing the glue code necessary to write
applications that displayed tables of data was very important. So we
developed the Enterprise Object Framework (EOF).

EOF had an NSController-like mechanism that used a class called
NSAssociation. NSAssociation objects worked like the bindings mechanism
-- they were a smart link between the controller and the user interface
object.

People loved EOF. I don't know how many times I heard the following: "I
used to use PowerBuilder, but it made 90% of the application easy to
write and 10% impossible." NSAssociation and careful use of delegation
made EOF easy to extend.

NSController and the binding mechanism suffers from PowerBuilder-like
shortcomings: As long as you do exactly what the designer planned, it
is quite convenient, but the moment you wander off this narrow trail,
misery ensues.

Here are the basic design flaws that plague NSController and the
bindings mechanism:

    1.     It eschews the delegation design pattern. This makes it
difficult to extend and inconsistent with the rest of Cocoa.

    2.     It uses a lot of private APIs. NSAssociation has been replaced
by NSBinder and NSBinderAdaptor. NSAssociation, however, was public and
easily subclassed. NSBinder and NSBinderAdaptor are private and
undocumented. Altering the default behavior of the bindings is
impossible.

    3.     It has no support for undo. EOF automatically registered all
edits, inserts, and deletes with the undo manager.

    4.     It has no support for relational databases. EOF could bundle all
those edits into tidy SQL statements and put them into a relational
database for you. This was made possible by a carefully defined data
source protocol. You could easily create your own data sources and slip
them under the controller.

    5.     It relies on unsavory hacks to the runtime system. For a
controller to know about changes to a model object, your accessor
methods need to notify it of the change. In EOF, the developer added a
call to [self willChange] to each set method in his model objects.
NSController (which doesn't trust you to do this) replaces your class
with a secret subclass that does the "right" thing.

    6.     It was created in a vacuum and rushed to market. No one at Apple
has ever created a realistic application with NSController.  The
design,  the implementation, and the documentation would all be better
if someone at Apple had been required to actually use NSController.

(Note that this is not a list of bugs -- those will disappear in time
-- but only basic design errors.)

I have met a few people who claimed that EOF was hard to use. These
people, regardless of what was written their business cards, were not
programmers. I'm glad that they decided to work in PowerBuilder or
Visual Basic -- I'm certain that regardless of the tool they chose,
these people never produced an application of any worth. EOF and Cocoa
were designed to give real power to real programmers. NSController and
the bindings mechanism were designed to give power to people doing
demos.

If good demos is the goal, NSController is sufficient, but if Apple is
serious about the enterprise, they should take a long, hard look at
this poorly thought-out mechanism and yank NSController. They could
replace it with something more like EOF. Heck, they could just
recompile the old Objective-C EOF source code.

These are harsh words, but someone should have stopped this train a
long time ago. The best I can do now is tell you not to get on.

Sincerely,
Aaron Hillegass

(To prevent a bunch of emails, let me mention that you will not be able
to buy the second edition of "Cocoa Programming for Mac OS X" for many
months. If you want a copy of the current draft, you should come to
class at the Big Nerd Ranch. We are offering a class Nov 10 - 14 in
Atlanta.)

(I've put a copy of this on the Big Nerd Ranch website:
   http://www.bignerdranch.com/Resources/nscontroller.html
)
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.