Re: Database Application with Obj-C
Re: Database Application with Obj-C
- Subject: Re: Database Application with Obj-C
- From: Kim Friesen <email@hidden>
- Date: Wed, 24 Dec 2003 09:34:44 -0600
Thanks Chris, I'm familiar with both SQL and EOF, that wasn't my
question exactly.
My point was :
In the context of Cocoa, EOF is not a shipping product and the few
various SQL Libraries don't really give you a standardized way of
interacting with databases or dealing with their exceptions to the
extent available in Python or Java. The few products that I have found
seem to be somewhat adhoc.
In both the Python and Java worlds there are various attempts to create
the OR Mapping products or Object DB type products. Even the database
library access is very well defined and standardized (JDBC, Python's
DB-API 2). Some of the efforts are commercial and have a lot of
support behind them but some are quite small groups and are open
source. Especially in Python's case, it seems like most of it's
progress is community driven.
As the question is asked repeatedly, is there something hold back Cocoa
? Is there lack of demand or interest ?
Are there Cocoa products that I'm just not aware of ? Do we just need
a product directory listing in a FAQ somewhere ?
Is the Cocoa community large enough to create standards / products that
fill this requirement or would it be better to wait for Apple to
provide this ?
On 23-Dec-03, at 3:26 PM, Chris Hanson wrote:
On Dec 23, 2003, at 9:36 AM, Kim Friesen wrote:
This topic seems to come up consistently. I'm curious as to why EOF
or SQL Libraries are the first things to be discussed.
SQL is just a language for communicating with relational databases.
EOF comes up because it was the persistence framework included with
Mac OS X Server and available for OpenStep, and it worked *very* well
there.
Is it because of Legacy databases that people want to connect to?
External reporting tools ? Interoperability ? I'm not sure that for
a new standalone or relatively small multiuser application that I
would like to have an unnecessary binding between my model objects
and a relational schema unless it buys me something significant.
What a framework like EOF gets you is semi-transparent persistence for
your business objects. The fact that it does it by talking to any of
a number of relational databases is just an added bonus. (That's in
the common case, EOF adaptors have been written for other data sources
too; WebObjects 5.1 and later include a JNDI adaptor for example, and
there was a flat-file adaptor in the past...)
I say semi-transparent persistence because you do still have to do
some work to create persistent business objects. You have to use
EOModeler to describe them and how they map to your data source, for
example. You also have to use some additional API to manage your
objects.
The thing is, this management is stuff you have to do anyway -- undo
support, saving, maintaining referential integrity, validation, that
sort of thing. So you may as well use a framework that does it for
you (possibly leveraging a common back-end).
-- Chris
--
Chris Hanson <email@hidden>
Weblog: http://www.livejournal.com/users/chanson/
Resume: http://bdistributed.com/people/cmh/resume.html
Looking for work developing Java or Mac OS X applications
_______________________________________________
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.