(excerpt from ASP.NET MVC in Action).
Views have long been abused in the Microsoft web application space. In Classic ASP, and in IDC/HTX before that, the view was the primary programming tool for the Microsoft-centric developer. Using the server page pattern, developers used IDC and ASP pages as transaction scripts to perform a single operation and render a screen. Each page has logic, behavior and UI. ASP.NET 1.0 sought to separate logic from the UI rendering in an effort to make applications easier to maintain and extend. Having logic intermixed with screen rendering had proved to be an unworkable solution for many teams. While it certainly was possible for teams to separate the concerns in their applications, Microsoft had provided no guidance on how to do so, and most samples and demo applications encouraged the intermingling of concerns. ASP.NET set the foundation for how a Windows web server would handle web requests. The framework has proved to be highly scalable and robust. One specific part of the framework that developers are most familiar with, WebForms, has underperformed expectations. The code-behind idea did, in fact, separate logic from UI rendering, but in practice, and coupled with guidance available in the industry, the logic ended up merely separated in a separate file instead of abstracted into new concepts. WebForms continued the server page pattern started in IDC and carried through Classic ASP. This server page pattern is being dropped with the new version of ASP.NET, ASP.NET MVC.
ASP.NET MVC views and WebForms views can coexist side-by-side, so it is possible to do a phased port from WebForms to ASP.NET MVC. WebForms, however, serve a much bigger purpose in the application than MVC views. For instance, by the time your code executes in a Web Form Page_Load, the framework has already:
- Selected the Web Form to execute
- Constructed the Web Form and all its design-time controls
- Processed any ViewState received.
With a Web Form, your code runs as the page is executing. There are plenty of ways to get into the pipeline before the page starts executing, but it is not obvious or easy. A Web Form is built upon the concept of a Control, which is the building block of the page. Controls can have child controls, and System.Web.UI.Page derives from System.Web.UI.Control. A control’s purpose is to be responsible for the behavior and rendering of what will ultimately become an html element on the web page. During the heyday of browser wars and incompatibility, controls were able to render different markup based on the browser receiving the page. This was a very useful feature in 2002 and 2003. With Internet Explorer 7 and FireFox 2+ now responsible for more than half of the browser markup, most web users employ a more standards-compliant web browser than was the case in 2002; therefore the risk of rendering the same markup to all users has been mitigated by the market.
ASP.NET MVC Views take back control of html markup. While it is possible to use existing controls for their rendering capabilities, the guidance with MVC views is to lay out the html by hand and use server delimiters to make parts of the view dynamic. MVC views leverage the Web Forms rendering engine but jettison the post-back logic, viewstate, and control hierarchy. An MVC view renders top to bottom and then goes away. An MVC view has much less responsibility than a Web Form. The view accepts objects in its ViewData dictionary and transforms those objects into a response suitable for the web. That is it. No decision logic, no permissions, no database access, no web service calls, just rendering. MVC views can still use a code-behind file, but they are not necessary. This ability comes from the fact that System.Web.Mvc.ViewPage derives from System.Web.UI.Page. If you are porting an application from Web Forms to ASP.NET MVC, you will find yourself moving much of your code-behind logic into a controller. You will also probably find that much logic does not even belong in a controller. You will most certainly need to develop additional classes to absorb logic that has inappropriately lived in a Web Form code-behind file.
Stay tuned for more: My feed: http://feeds.jeffreypalermo.com/jeffreypalermo
You will also want to pay attention to my co-authors: Ben Scheirman and Jimmy Bogard.