On Wed, Feb 11, 2009 at 10:42 AM, Jason Wiggins <jwigg...@optusnet.com.au> wrote:
> I understand MVC ... Sorry, but I disagree. You've still got some concepts missing. :-) > Now, I understand I need a pointer to the "other object", but I am failing > (in a BIG way) in understanding HOW to get it or create it. > myControllerObject has a pointer to it's children because it knows about it > because it created it. In MVC, it's typical for your controllers to be responsible for creating the model objects. Consider an app that manages a "library" of things. For simplicity, it's only one kind of thing. The left-hand pane might be a "source list" style table listing all the objects in the library. You might call this the "LibraryController". It's responsible for creating, deleting, reordering, and overall managing LibraryItem model objects. By making this the sole responsibility of the LibraryController, there's always only one place that a LibraryItem instance would be created. If the LibraryController created it, the LibraryController is free to set its properties any way it wishes, including "[object2 setOtherObjectYouNeedToKnowAbout:object1]; > But if modelObject1 doesn't know modelObject2 even exists, how can I create > a pointer to it? Where do I get this reference from? Never said that. It's quite common for model objects to know about each other. It's just as common for controllers to know about one-another. It's just not "right" (according to MVC) for the model *layer* to know anything about anything in the controller or view *layers*, even if they're designed to work together. Consider Core Data. It's an "object graph management and persistence framework". If we ignore the persistence part (ie, we're not interested in Core Data's file saving capabilities, only its object graph management capabilities), we still get a *very good* system for managing an object model (the schema as well as the actual graph of object instances that your app creates / manipulates). An Employee object needs to know about a Department object (and vice-versa) because they have a relationship. So a Department must have an -employees property (an array or set) to which Employee instances can be added or removed (or re-sorted, etc.). Likewise, an Employee must have a -department property (it's a two-way relationship, after all). When an employee instance is created, that's the ideal time to set its -department (or, the other way, when a new department is created, you'd add employees). Core Data handles this very well (makes it easy), but without it, you need to enforce that logic yourself. Still, see my LibraryController points above ... a controller is responsible for actually manipulating / managing the model. -- I.S. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
