Re: The Problems with NSController
Re: The Problems with NSController
- Subject: Re: The Problems with NSController
- From: "Francisco J. Bido" <email@hidden>
- Date: Sun, 26 Oct 2003 11:18:13 -0600
To Aaron's defense, his criticism is very constructive. For my part,
I've just begun to play with NSController so my comments are to be
interpreted in the light. I've decided to reply to this thread, since
I figured that a considerable number of Developers are in my same
position. To get to my point, I don't really see where this is going
to be really useful...
It may eliminate a few lines code but so what? I found the notification
mechanism a bit clumsy and one that will not make a beginner's life any
easier. So if this is not for beginners then who is it for? Experience
programmers don't care about writing a few lines of extra code, if it
means more control. It would have been nice to be able to abstract SQL
calls in some way -I'm not of the EOF generation, although in the right
age group.
I will continue to dig into this but merely out of academic curiosity.
I hope that Apple provides some more examples of where the real value
is. At this point it seems to be trade off between not writing some
extra (very easy) code and the intuitiveness of dragging wires from IB
widgets to a standard controller.
Francisco
On Oct 26, 2003, at 8:42 AM, 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.