The Model-View-Controller framework is centered around the Controller. In the Java world Struts is a very popular example of an MVC Web Application Framework. The general idea is that the controller is responsible for the navigational code, i.e. it controls the application flow. The view simply renders the information stored in the model. Although MVC provides a certain level of separation of concerns, the view is often tightly coupled to the model. On the other hand the application flow is separated from the view, thus providing better means of reusing views as well as a cleaner web client implementation.
Jeffrey Palermo describes how the MVC framework prototype works:
With Scott's prototype, there is a new handler factory that infers from the URL which controller to instantiate and load. The controller then decides what to do with the request. The controller can load a view (.aspx file) and let it render. The view can access properties of the Controller. The ASP.NET lifecycle and control model and still be used in the view, or you can let the Controller render a view of customized templates. Either way, the Controller is in control.Besides supporting separation of concerns, MVC allows for an easy way of unit testing web clients. The flow of actions can be tested without instantiating (real) views; mock views can be used instead.
Joost gives some explanation of the Model View Controller pattern in web applications in his article, also naming the pros & cons:
Today the Model-View-Presenter pattern is used for separating model, view and application flow in the ASP.NET world, e.g. in the Web Client Software Factory. Sometimes MVP is seen as an improvement of MVC, making use of its strengths and at the same time avoiding its disadvantages. Martin Fowler provides a nice overview of current GUI Architectures. Within the article he explains the different paradigms for developing GUIs:
- What's so useful about it
- Separation of requests and pages
- Views are dumb
- Shielding of the Model implementation
- Problems and limitations
- What goes where
- Coupling between View and Model
- Lots of objects
To approach MVP I find it helpful to think about a significant mismatch between two stands of UI thinking. On the one hand is the Forms and Controller architecture which was mainstream approach to UI design, on the other is MVC and its derivatives. The Forms and Controls model provides a design that is easy to understand and makes a good separation between reusable widgets and application specific code. What it lacks, and MVC has so strongly, is Separated Presentation and indeed the context of programming using a Domain Model. I see MVP as a step towards uniting these streams, trying to take the best from each.Concerning the value of the MVC framework for ASP.NET Jeffrey Palermo concludes:
This is very cool, and ScottGu is headed in the right direction. I'll vouch for that. We're going to end up with a new ASP.NET paradigm that so much easier to work with and, most importantly, easier to test!What are your experiences with Web Application Frameworks, the MVP or MVC pattern and what do you think of MVC for ASP.NET?