On Jan 18, 2012, at 6:12 PM, Marcel Weiher wrote: > On Jan 14, 2012, at 18:37 , Kyle Sluder wrote: > >> The UI will register as a KVO observer, or as an NSNotification observer, or >> perhaps the controller will just call -setObjectValue: directly. > > In my experience and opinion most of these are tempting, but ultimately lead > to bad results because of the type of model to view coupling that you are > supposed to avoid in MVC. The model should be able to send invalidation > notices to the view, but not push values. The view should react to the > invalidation notices by requesting new values from the model. At least this > is how the original Smalltalk MVC worked ( models are ideally passive and > don't even know about views, controllers manage the changes; if that doesn't > work, models send "#changed", which then causes the view to take proper > action to react to that change).
What you are saying "should" be the case is, in fact, exactly how KVO and bindings actually work. You seem to be vehemently agreeing with Kyle, while claiming to be disagreeing. >> Breaking this pattern should be a conscious decision. > > I'd say that the opposite is true: in general you should avoid specific > model -> view communication as per MVC (apart from invalidation), but in > specialized and very simple cases you may be able to get away with it. KVO and bindings are not "specific model -> view communication", they are a generalized mechanism which avoid coupling. The model just supports a generalized observer pattern. It doesn't know anything about its observers; it doesn't even know or care whether there are any. Regards, Ken _______________________________________________ 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
