Just to clarify a possibly misleading paraphrase from
the start of this thread, here is the actual text:
Excerpt starting on Page 129 in "Cocoa Programming"
ISBN 0-672-32230-7
MVC in Cocoa
By making this separation into three layers, an
applications interface and internal
data structures are decoupled. As a result, the
potential for object reuse between
applications is enhanced. A generic view object, such
as a text field, could be created
and then reused in many different, unrelated
applications. A model could be used in
different applications that provide different ways to
access or modify the models
data. For example, perhaps you have a desktop
application for manipulating some
data and a secondary command line or Web interface
that allows access to the same
data. Just like generic-view classes and
specialized-model classes can be reused,
generic-controller classes can also be reused across
unrelated applications.
The Foundation Kit offers many data structures that
provide a basis upon which a
model can be built. This allows you to concentrate on
what makes your model
special as opposed to reimplementing yet another
standard data structure. In theory,
this layer is where most of your code-writing time
should be spent because the
model is the part of your application, which makes it
truly unique.
Cocoa supplies a wide variety of views in the
Application Kit, therefore, many appli-
cations will not need to create their own custom
views. This is a huge time saver,
and one of the ways that Cocoa can improve your
productivity.
If you are creating a document-centric application,
then the various classes surround-
ing the NSDocumentclass will provide much of the
controller logic you need. The
NSDocumentclass is described in Chapter 9,
Applications, Windows, and Screens.
Sadly, in other parts of the controller layer, Cocoa
does not yet provide much help.
The Application Kit focuses on the view layer, whereas
the Foundation Kit focuses on
the model. There is no generic controller framework.
The lack of a controller framework is one area that
could stand improvement. Note
that Apple does have some generic controller objects
that would help. They are in
the EOInterface framework, which is a part of the
Enterprise Objects Framework.
Unfortunately, this is not a part of Cocoa, so it
isnt something every Cocoa devel-
oper can use. Perhaps sometime in the future these
classes, or something similar to
them, will become a part of Cocoa.
Until that time, however, there is no controller
framework that is a part of Cocoa
itself. As a result you will often spend time writing
code for your applications
controller layer. Most developers dont design and
create reusable, generic-controller
classes because it is difficult to do well and takes
much more time to create the
objects. Few developers have the time and resources to
do it right, so most Cocoa
application developers create their own controller
classes each time. This is reason-
able, especially given the time constraints of most
projects. Unfortunately, very few
of these custom classes are reusable from one
application to the next.
--------------------------------
Indeed, as "Cocoa Programming" was being written,
Apple was busy developing the KVC/KVO controllers and
bindings technology in Cocoa. They qualify as
"something similar" to EOInterface even though there
are certainly important differences.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
This email sent to email@hidden
