Re: Core Data design patterns
Re: Core Data design patterns
- Subject: Re: Core Data design patterns
- From: Jerry Krinock <email@hidden>
- Date: Sun, 19 Jul 2009 15:15:08 -0700
On 2009 Jul 19, at 13:59, Squ Aire wrote:
Thanks for these wonderful answer and tips.
I like how you have designed this stuff. Gladly, it is similar to
what I've been doing. Based on this I can now refine my own stuff,
e.g. by doing a subclass for each entity like you are doing.
Don't get too excited yet. If you can find something else to do today
it might be good to wait until someone with more experience (and maybe
one of those CS degrees) chimes in.
* About your error handling, how do you do it? My code differs in
this respect, because in my CoreDataHelper I mentioned I have up
until now had this handleError: method that takes in an NSError and
whenever the error occurs, the model just calls this method and
handles it internally. This means that I don't have to do any error
handling in my Controller classes, making development easier.
and the product "cheesier" :)
Does this, however, break any design principles?
Well, I wouldn't call it a design "principle", it's more of a
"desirable goal" that errors should be bubbled up to the highest level
and presented to the user. It makes for a much cleaner high-level
design, and you should always consider doing this. But sometimes it
makes the code a little too pedantic if every damned low-level method
has an (NSError**)error_p parameter.
The case in point here is that -[NSManagedObjectContext
executeFetchRequest:error:] returns an NSError if something goes
wrong. Well, say that this fetch request is not actually for fetching
data to the user interface but to implement some other business logic,
so there might be 3 methods on the call stack. And then by the time
you build a predicate you're going to get several more. I mean,
something as low level as a fetch request might have ten methods above
it in the call stack, and I don't want to be carrying an NSError**
parameter through all of them.
To handle that, as you can see, my SSYMojo's initializer takes this
parameter:
(NSObject <SSYErrorHandler> *) errorHandler
The formal protocol <SSYErrorHandler> declares an 'error' property.
So when an error occurs in, for example, a fetch request, the SSYMojo
sends setError: to its errorHandler. The errorHandler is something at
a higher level, for example, my Core Data document, which checks that
its 'error' property is nil after doing anything significant.
I may afford to do this because all my error handling did was to
terminate the app using [NSApp terminate:self] and doing some NSLogs
of the error information.
Great for in-house work! But I don't think my users would like that ;)
(In fact, doing even that sometimes didn't terminate my application;
how can I guarantee my app terminates? [NSApp terminate:self];
didn't seem to do the trick actually.)
I've never seen this not work. Post some code.
However, when you want to show some feedback at the UI level of
errors, my method of handling errors in the model might not be such
a good idea.
Yes, but Apple's -presentError: is not very user-friendly, and also it
discards most of the goodies in the error's userInfo dictionary.
Ultimately, you'll want to override -willPresentError: and present the
error in a custom sheet or dialog, while you copy the goodies into a
full error report that users can send to you.
* Finally an unrelated and basic Core Data question: Where do you
paste the code you copy using the "Copy Method Declarations/
Implementations" feature in the data modeling tool? I really want to
use those things because it is, according to docs, faster than
valueForKey, setValueForKey, etc.
Up until now, I have tended to make a subclass of each of my managed
objects and pasted the declarations/implementations in there. Do you
think this is a good idea?
That's where I put them. Of course, you are heeding the "You do not
need any of these" warning and only using these implementations if you
^really^ need to override an accessor. (Unfortunately this occurs
quite often due to the skimpy information you get from
NSManagedObjectContextObjectsDidChangeNotification -- Apple Bug
6624874).
_______________________________________________
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