Re: Cocoa Technologies Back-Story?
Re: Cocoa Technologies Back-Story?
- Subject: Re: Cocoa Technologies Back-Story?
- From: Hsu <email@hidden>
- Date: Sat, 30 Apr 2005 16:50:28 -0700
Bindings:
Whose idea was it try to eliminate the controller layer?
The controller layer hasn't been eliminated; merely automated -
bindings essentially replace custom controller classes and methods with
apple-provided generic reusable controller classes and
key-value-coding. It is similar to Associations from WebObjects. Apple
realized that while it's important to use the MVC paradigm, much of the
Controller code is pretty generic - Bindings is the realization that if
it's generic, it can be provided by a framework+runtime without minimal
effort on the part of the developer.
Is there a history to trying to do this outside of Apple/NeXT?
If so, do those approaches go by a different name?
No idea.
Core Data:
Is this database technology?
Is it "normal" to apply database technology to application design?
It's object graph management with persistence. The persistence can be
to various places - flatfile, in-memory, databases, etc.
Similar to bindings, CoreData is the realization that much of the
"Model" of MVC is generic as well - the interesting thing to a
developer is the structure of the data and the relationships between
data. There is also the happy understanding that frequently, when
"saving" the developer merely wants that data to be persisted to disk.
CoreData is database technology in that it came from EOF (Enterprise
Objects Framework) the object-relational mapping layer for WebObjects.
(EOF came out of a NeXT desktop technology that escapes my mind at the
moment).
Is there a debate about whether database "entity modeling" should be
used in desktop applications?
Not that I know of. It's a bit like asking if there is a debate on
whether GUI should be used in desktop applications. The answer is
"yes", the interesting question is "how". (Though to be pedantic, I
mostly mean "entity modeling" not the "database" part).
Should I feel warm and fuzzy about designing my application's model
this way instead of in a more "dictionary-oriented" way?
A dictionary is a poor-mans CoreData :) Seriously - you have a generic
object that stores data, referenced by keys (typically strings). If the
"data" is a pointer to another object, that defines a relationship. If
the "another object" is another container (array or set) you have a
to-many relationship.
A key difference between a CoreData "Managed Object" and a Dictionary
is that a "Managed Object" is...well... managed. Changed to the MO are
tracked, and can be undone/redone, as well as easily validated. Since
the entire state of the all the MOs and their relationships are known,
the entire thing can be persisted easily.
Karl
--
FNORD
Homepage:
http://homepage.mac.com/khsu/index.html
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden