>>>At the heart of MVC, and the idea that was the most influential to later frameworks, is what I call Separated Presentation. The idea behind Separated Presentation is to make a clear division between domain objects that model our perception of the real world, and presentation objects that are the GUI elements we see on the screen. Domain objects should be completely self contained and work without reference to the presentation, they should also be able to support multiple presentations, possibly simultaneously. This approach was also an important part of the Unix culture, and continues today allowing many applications to be manipulated through both a graphical and command-line interface.
>>>In general data binding gets tricky because if you have to avoid cycles where a change to the control, changes the record set, which updates the control, which updates the record set.... The flow of usage helps avoid these - we load from the session state to the screen when the screen is opened, after that any changes to the screen state propagate back to the session state. It's unusual for the session state to be updated directly once the screen is up. As a result data binding might not be entirely bi-directional - just confined to initial upload and then propagating changes from the controls to the session state.
The reason of this? Because Windows update the view, not the model, so, we have two directions: view to model (user change), and model to view (code change). It could be (real smalltalk-MVC) that the window update the model (of course, this means that we always need a model behind a view – this leads more “complexity”, and since M$ traditionally only focuses on dummies, so, they do not want that – however, on the web, there is really no other way (http protocol makes smalltalk-MVC impossible), so, M$ is actually good: it makes the web and windows that same. As a result, the following solution applies to both windows and web.
To correct the problem, we can use databinding (to simulate that it always reached the model), and also, the model always automatically raise the event to update view (there is a bug here in 2005: it does not update the originating field – I guess the bug is a misplaced intent to prevent possible forever loop, however, the intent is misplaced, because the forever loop can be prevented by compare the value – if there is not difference, then, no update – and the rules is already there. The solution of the bug is to force a update. For details see: http://www.lhotka.net/weblog/WindowsFormsDataBindingIssueConclusion.aspx).
Combine the two corrections: yes, view is smarter: it can “bind” model, and it intercept controller. However, view is still humble view. The “local controller” within the view can handle a lot of things, and it passes the “big” events to “global-controller”. For the ASP, the “global-controller”, we can use a utility class to contain all the logic. The working separation of “local” and “global” is that whether the “global” should be able tested without UI (web container) – but it must know the interface of the view.
MVP gives ASP a good name. Pure MVC requires give up ASP all together (but look at castle igloo: http://www.ayende.com/Blog/archive/2007/01/26/6918.aspx ). However, considering JSF is still trying to mimic ASP, you have to hesitate to throw the baby away just because of the dirty water.
MVP is the evolutionary approach: basically, it does not introduce anything special, just use asp the right way.
---- this article has all the details! It is very interesting to see it that if you always wrap everything in a user control, then, the page is only flow-definition-mechanism. So, the real thing are in user controls, pages are for flow-definition (and master pages are for layout, cool).