Re: ADC Core Data article

FROM : mmalcolm crawford
DATE : Wed Apr 06 09:52:54 2005

On Apr 5, 2005, at 11:22 PM, Paul Szego wrote:

>
> On 06/04/2005, at 2:48 PM, Will Mason wrote:

>>> On the other hand, if you don't need all these services and just aim
>>> for persistence, CoreData aren't what you need: just use an
>>> NSArchiver, and you get the support for any NSObject :))
>>>

>>
>> No, you don't. An object can be archived (sent to/read from an 
>> NSCoder)
>> only if it adopts the NSCoding protocol.
>>

>
> A similar approach for CoreData would be better. Having a base 
> class that implements this for free is a good thing, as long as 
> that's not the only way to do it. Hopefully you wont be forced to 
> extend a specific base class - that's just bad design.
>

The article is very clear:
"By default, the class used is NSManagedObject, but the class may be 
either NSManagedObject or a subclass thereof."

If Core Data only addressed object persistence, then it might be 
argued that this would be poor design.  As noted earlier, however, it 
also solves a much more difficult problem, and one that really only 
affects data objects.  Given the functionality that's provided for 
free, requiring that your model classes inherit (ultimately) from 
NSManagedObject instead of NSObject does not seem too onerous (I 
suspect in most cases this will simply involve adding 7 characters to 
your declaration...).

Indeed it's reasonable to argue that putting all the functionality of 
a model object into the root class would be bad design.  It would add 
an unnecessary overhead to all the other system classes, from views 
to controls to strings (which don't need to know what entity they 
represent or what context they belong to(*))...

mmalc

(*) "In order to be properly managed, a data object needs to be 
associated with its managed object context and an entity definition 
that is part of the managed object model that is being implemented by 
the context."