kothapallibc wrote: > <Quote> > MVC says that views should update themselves. I think the most > important argument may be, that views are considered the most > volatile layer and models the most stable. So it is OK for views to > depend stongly on models, but it is not OK for controllers to depend > strongly on views, because the frequent changes in the view layer > would generate changes in the more stable (and often more > complicated) control layer. In the blueprint architecture this would > also be the case, if a controller should update the views. > </Quote>
That might depend on what MVC you are talking about. I've corresponded with the architect of the original SmallTalk MVC framework, Trygve Reenskaug, who tells me that the Observer pattern (which allows views to update themselves) is not required by MVC. "MVC can stand on its own without the Observer pattern" [Reenskaug, 28-Dec-2001]. In Design Patterns, both the MVC framework and the Observer pattern were introduced in the same example, which has tended to join the two over time. But in terms of the original SmallTalk MVC framework, the observer pattern was often used, but is just one of many possible approaches. Many MVC ~implementations~ were designed for desktop applications on local networks, and so the Observer pattern was a good way to go. But MVC implementations for remote applications are better designed using the Layers pattern. Here, the controller mediates between the view and model, since they are not on adjascent layers. [view] <-> [controller] <-> [model] This gives the controller the ability to obtain data from disparate sources, and bundle it up for the view, without the view needing to be involved with where the information originates. The Observer pattern can be used with Web MVC, but the controller should be the one subscribing to the model, so it can push the updates to the view as needed. -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
