Re: Core Data Abstractions
Re: Core Data Abstractions
- Subject: Re: Core Data Abstractions
- From: mmalcolm crawford <email@hidden>
- Date: Fri, 3 Jun 2005 00:14:12 -0700
On May 31, 2005, at 1:55 PM, Timothy Reaves wrote:
As to the loose wrapper around a rdbms, that's not true
either. In a
RDBMS world, if I want all instances of an object, I simply execute
'select * from myTable', I do not create another table and add all
instances of the second table to it.
Or more clearly stated, the extra entity mmalcolm refers to IS
the
table; I need create no extra db object to track those for me.
[...]
It is unfortunate that people can not seem to break free of a
relational / procedural world. Objects work so much better with -
well, objects - then they do with relation tables. Isn't that why OO
languages are chosen over procedural languages?
It's ironic that you're railing against a pattern that does not make
sense in the database world, but does in the object world. Certainly
if you were using an RDBMS it would not make sense to add another
table. We're dealing here, though, with objects, and attempting to
deal in a pragmatic way with the difficulties people have with
collections of objects.
Let's suppose, just for the sake of illustration, that someone were
having problems with the relatively straightforward task of within
their application keeping track of all the instances of a given
entity. They could write some fairly easy logic to do so
(registering as an observer for managed object context change
notifications, adding logic to the controllers they themselves own,
etc.) -- but in some cases that seems to be a little too difficult.
As a pragmatic alternative, they might define a new entity of which
there were a singleton instance and to which all the instances of the
other entity were related. (Note that the suggestion here is not to
create an arbitrary "*Manager" entity, but rather one that makes
sense in the context of the problem domain. Thus in a Books
organiser, an appropriate entity might be "Library".)
Would this win prizes for academic purity? No. Is it the optimal
architecture for addressing the problem? No. Is it a "nasty hack",
riding up there with poking at a private instance variable in a
persistent store object? No. It's doing something object-oriented
that leverages the benefits of the framework, and certainly falls
within the scope of the framework's normal abilities.
If CoreData at an implementation level wants to be a thin wrapper -
Hibernate from the Java world if you will - that's (almost) fine, but
hide the procedural stuff from me, and let me play with objects.
You are welcome to play with objects. What "procedural stuff" is
Core Data exposing you to?
I write very large multi-million dollar software systems for very
large fortune 500 companies using Java. Hibernate is very widely used
It's not clear what is the purpose of trying to play "My credentials
are bigger than yours"?
You also seem to miss the point that the primary focus of Hibernate
is object persistence. The main value of Core Data is object graph
management.
at the moment because of the promise of using objects and hiding all
the SQL code from your program (Parc estimated that 60%-70% of code in
an OO application & relational db was SQL related). What companies
are finding out is that Hibernate introduces as many problems as it
solves, and makes the developer muck around much more with SQL &
RDBMS' that anyone at first blush believes will be needed. So much so
that there is already a big push away from Hibernate for all but the
smallest applications. I hope CoreData does not go the same way.
I'd be interested to know how you're currently intending to use SQL
with Core Data?
mmalc
_______________________________________________
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