views:

117

answers:

2

Hello,

In classic MVC the model notifies the view about changes made on it. In C# this means I have to subclass the View I'm interested in and in the subclassed class register to the model's event. For example, if I were to implement MVC using C# and Winforms, I had to subclass TextBox class and then register inside the MyTextBox's constructor for the model events. Am I correct? How was this issued in Smalltalk? Does one also need to subclass every View in order to register the model's events, or is there some way to dynamically add events to the views on the fly?

Thanks

A: 

I think the MVP pattern would be more appropriate for your winforms UI application.

http://stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-difference

Bryan Rowe
thank you very much
kernix
+1  A: 

To address the sub-question about how Smalltalk (from which MVC originates) handles this: originally (this is Smalltalk-80, where Trygve Reenskaug implemented MVC) it was indeed necessary to subclass the view superclasses for your specific view to register it as a subscriber to change events from a concrete model subclass. Controllers in Smalltalk were only to delegate or dispatch window events (esp. keyboard and mouse) to the model. Basically you can say the controllers modified model objects, and view only showed them. However the concept of Dynamic Values, or ValueModels as they became to be called, made this approach obsolete in VisualWorks Smalltalk. Now you could create a standard GUI framework, no need to subclass anymore, and every view would be able to register itself as an observer to an abstract model class. The model for the view would not be a model class anymore but a value model with a standard interface. More on this here: http://st-www.cs.illinois.edu/users/brant/papers/ValueModel/ValueModels.htm

robject
Nice (+1) That said, there's a reason Adele never wrote the book and only 'The Black Art of MVC Programming' to 'splain things.... The controller always got polluted with view and model specific information, which is what led to the visualworks change - also to some other newer patterns like MVP (Model-View-Presenter)
Mark Mullin