re: request for advice on using Core Data
re: request for advice on using Core Data
- Subject: re: request for advice on using Core Data
- From: Ben Trumbull <email@hidden>
- Date: Sat, 23 Jun 2007 17:06:33 -0700
Wagner,
While you can do what you propose in Core Data, it will probably be
more obfuscating than facilitating. Core Data provides two broad
categories of services: persistence and change tracking.
It's not clear to me your application needs either.
If the modeling tool will help you organize your application with a
cleaner MVC pattern, by all means, use it. You can create
NSManagedObjects without using any of the other Core Data features.
It can be quite handy as NSManagedObjects have many default behaviors
that are convenient extensions of NSObject.
However, I would expect that you could leverage all UI aspects of
Cocoa will less effort by simply creating your own subclasses of
NSObject that follow the naming conventions to be KeyValueCoding &
KeyValueObserving compliant (i.e. compatible with Cocoa Bindings)
As for your other questions:
(2) Core Data only supports the notion of to-many relationships that
are sets, not arrays. However, it does allow for transient
properties that can be arrays. How you should model depends on how
important the ordering information is. Most people can live without
it, and provide sorting in the UI explicitly. Letting Core Data use
it's built in to-many relationships will be easier and faster. But
sometimes ordering is a crucial bit of data that needs to be stored.
(3) Entity inheritance and class inheritance are orthogonal. Class
inheritance, is well, you've used Java, you should have an idea.
Entity inheritance describes how the data is structured. Entity
inheritance hierarchies are very shallow and do not look like typical
class hierarchies. The key question to ask about whether a property
should be duplicated between entities, or part of entity inheritance,
is whether most of the time you want a fetch to return a
heterogeneous collection of different entity types or not. Most
beginners tend to overuse entity inheritance.
(4) Decoupling your DS logic from the UI work should be straight
forward by simply using different classes and composition. As it's a
sample application, the division doesn't have to be perfect. Your
objects can use KeyValueObserving for finer grained notifications and
post NSNotifications for broader changes. Unless you have an
extremely large data structure, for a tutorial application, you could
just redraw all of it after a series of changes.
You're probably best served by learning about KeyValueCoding,
KeyValueObserving, and Cocoa Bindings.
--
-Ben
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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