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 protected])
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
