Re: Core Data using only one object
Re: Core Data using only one object
- Subject: Re: Core Data using only one object
- From: "Corey O'Connor" <email@hidden>
- Date: Tue, 24 Apr 2007 17:24:53 -0700
On 4/24/07, Steve Israelson <email@hidden> wrote:
Well, what I meant was I have an entity type called "GraphicNode" and
it has attributes that are used to describe this node class.
The user will make use of instances of the class these describe,
probably by me calling a factory method to create a new node.
These can't all be different types of entities because how would my
code ever collect em all up into a palette to provide a list of
things for the user to drag into their document?
There doesn't sound like there is a requirement for a persistent store
in this case. So CoreData is likely not useful. Maybe palette
settings, but that'd be orthogonal to specifying the composition of
nodes. There also doesn't seam to be any reason why Core Data cannot
be used as the persistent store for the information about the node
instances. The palette would just provide information to construct an
instance and shouldn't constrain how that instance is represented too
much.
>
>> 2) Put the list of I/O data types as a set of one entity type.
> List of I/O data types per node? I'd presume such a list is dependent
> on the node type (Bound at compile time) and some parameters specific
> to the node (Possibly bound at runtime).
This list is descriptive. Each class above would describe in a
general way how many possible inputs there could be and whay type it
is by linking its type relationship to one of these guys.
The more variability something has at runtime the less suitable Core
Data is to represent it IMO. Still I bet the set of node types is
known at compile time and each node type constrains the set of
possible connection types. So it's still possible Core Data would
provide a useful persistent store system.
> You actually have to do the reverse: Define the classes to be
> subclasses of NSManagedObject. A NSManagedObject instance will take on
> the role of a specific entity according to the description in your
> managed object model.
I was considering this, but once I started going there I was asking
myself what the heck CoreData was giving me then?
This is the basics behind my original comment. How and why to use
CoreData and some REAL world examples, not simplistic ones.
Core Data (almost) has a feature I find all great APIs do: The ability
to use as much or as little of the system as desired. The cost profile
of using a little bit of Core Data compared to using Core Data for
everything is, admittedly, a bit steeper than I'd like, but I don't
find it unreasonable. I've used Core Data successfully for projects
that have even involved C++ systems.
I have one app with probably 50 different entity types all
interconnected in complex ways, and I ask myself if this is sanity or
not.
Hard to say given the level we've gone into the requirements and what
implementations would satisfy those requirements. I suggest playing
with making some simple Core Data applications to learn where the
system can fit into larger systems. I can't produce a good description
but it didnt' take me too long to gain that understanding on my own.
--
-Corey O'Connor
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden