Re: Design pattern for core data, document based, graphical application
Re: Design pattern for core data, document based, graphical application
- Subject: Re: Design pattern for core data, document based, graphical application
- From: Erik Buck <email@hidden>
- Date: Tue, 17 Aug 2010 08:33:48 -0700 (PDT)
You have too many design options on the table. Try some of them in mini-prototypes to see how well they work and then drop some of the ideas.
I have used Core Data to store Model data for 2D and 3D drawing/visualization applications. My approach was to use the Core Data designer to specify custom subclasses of each Core Data entity (NSManagedObject subclass). Then I don’t touch the custom subclass files themselves. I add methods for drawing to each subclass in categories. That way, the designer can regenerate the subclass interface and implementation files as many times as needed without impact to the code added in categories.
For example, a Core Data entity for a “GraphicalThing” might have a “color” attribute stored as an archived NSColor instance in NSData. It might have an “isFilled” attribute stored as a Boolean. Then, a “CircleGraphicalThing” sub-entity of “GraphicalThing” is implemented as a subclass of GraphicalThing and add float attributes for “centerX”, “centerY”, and “radius”.
Drawing pseudo code might be
@implementation CircleGraphicalThing (Drawing)
- (void)drawInContext:(id)aContext
{
NSColor *currentColor = [self transientColor];
if(nil == currentColor)
{
currentColor = [NSUnarchiver unarchiveObjectWithData:[self color]];
[self setTransientColor: currentColor];
}
[aContext setColor: currentColor]
[aContext drawCircleAtCenter:CGPointMake([self center], [self centerY])
radius:[self radus]];
}
@end
Drawing is not the Controller's responsibility. Drawing is a View responsibility, but in a drawing application, Model objects draw. If you need to support multiple types of View such as an OpenGL View in addition to a Quartz2D View, just have multiple categories. Add a -drawInOpenGLContext: method in a different category. Store the category implementation files as part of the View subsystem even though they extend Model objects.
Most of your other questions are resolved using Controllers in ways that are independent of the Model details. For example, synchronous side effects are handled nicely by bindings that are set up in Interface Builder without any impact to the Model. A synchronous notifications are discouraged but can be accomplished with -performSelector:withObject:afterDelay: or by putting notifications in an NSOperationQueue, etc.
_______________________________________________
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