Re: The Problems with NSController
Re: The Problems with NSController
- Subject: Re: The Problems with NSController
- From: James Masasaki <email@hidden>
- Date: Sun, 26 Oct 2003 11:54:58 -0800
So, if I am to understand you correctly, what you are saying is to
*not* use NSController *at all*?
Thanks,
James
At 9:42 AM -0500 10/26/03, Aaron Hillegass wrote:
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@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.