Re: EOF (was Re: Cocoa CGI)
Re: EOF (was Re: Cocoa CGI)
- Subject: Re: EOF (was Re: Cocoa CGI)
- From: mmalcolm crawford <email@hidden>
- Date: Fri, 18 May 2001 06:29:20 +0100
I wrote:
[Lots of stuff about a Persistent Objects Framework]
On reflection I missed out one of the most important aspects of EOF, and
ironically the aspect I'm about to chastise others for overlooking! :-)
In many respects EOF is most easily understood as a means of
manipulating data stored in a database. A couple of issues arise,
though:
(a) Do you I to know SQL?
(b) I'm not interested in this "enterprise stuff".
(a) Do you I to know SQL?
No. EOF does all its magic for you. You can get under the hood and
create custom SQL if you want, but you're encouraged not to do so, and
simply write code, e.g.
[anEmployee setDepartment:aDepartment];
EOF handles all the primary and foreign key stuff for you, etc. etc.
You might have now twigged that this means that to the programmer EOF is
database-independent.
One of the (generally fairly trivial) things you have to do for an EOF
application is to generate a mapping file, known as an EOModel. This
defines what class in your app corresponds to which table in the
database, and which instance variables in your class correspond to which
columns in the table. You can have subsets of each if you like.
Most of the work of creating this file is done for you automatically
when you create the EOModel in EOModeler. EOModeler interrogates the
database you point it at, and figures out most of it for you.
The reason you're insulated from SQL etc. (and this was all done years
before JDBC) is that EOF also has *adaptors*, specific to each database
type, which translate the EOF operations into SQL specific to the
database.
(b) I'm not interested in this "enterprise stuff".
If you think really hard about that last point from (a), you might
realise that there is actually no reason why EOF has to point at a
relational database.
You should be able to point it at any persistent data store, if you can
write an adaptor for it.
One such adaptor that's provided for you is a flat file adaptor. So if
you want to archive yor objects just to a filesystem, that's fine.
I hope that these rather long posts might have given some folks out
there a flavour at least of what EOF is about, and why it is perhaps
rather unfortunately named. "Enterprise" objects may not sound as if
they have a great relevance to the Macintosh marketplace (at least not
yet ;-) , but I hope anyone should be able to see the benefits of a
Persistent Object Framework, and why some of us would so dearly like to
see it retained in Cocoa.
And I haven't even mentioned the EOInterface framework yet... if it's
not too cruel to ask, perhaps Brian might explain the loss he's feeling
at the moment?
mmalc.
| References: | |
| | >Re: Cocoa CGI (From: mmalcolm crawford <email@hidden>) |