Channels ▼


Web Development Renewed

Dino Esposito is a consultant and author who specializes in Windows development.

ASP.NET is a stable, mature, and productive Web development platform, but the 8-year-old framework is showing signs of age.

One alternative is MonoRail, a variation of the classic Web Forms model based on views (the HTML output) and controllers (methods executed in response to requests). MonoRail's views are produced by an ad hoc engine that uses a source template and input data to produce the HTML.

With MonoRail, you don't focus on pages as you do with Web Forms. Instead, you focus on the actions being taken from the page (methods on a controller class) and its user interface (markup and data placeholders in the view). This leads to separation of concerns (SoC), where the functions of each feature in the program overlap as little as possible, and higher testability.

But you have to abandon ASP.NET to get more control over HTML and SoC. It's possible to produce better ASP.NET Web Forms pages that have an increased level of testability and SoC by handcrafting code-behind classes to place code in a separate file. Nevertheless, the ASP.NET runtime environment isn't designed with extensibility in mind, and the Page Controller pattern that it uses inherently leads to black-box solutions that limit developers' freedom.

Another ASP.NET alternative is the Model-View-Controller pattern. It's used to create the Web Client Software Factory, a collection of reusable components and libraries for building Web clients that rely on the MVC pattern to generate the UI. WCSF comes with Visual Studio templates, automated tests, and wizards for speeding up development. But it's a productivity tool for complex, mostly enterprise-class applications and may not be appropriate for run-of-the-mill Web development. That's why the preferred option is ASP.NET MVC.


ASP.NET MVC 2.0 is a free Web framework that gives you control over your HTML and URLs, facilitates Ajax scripting, and encourages test-driven development. Based on the ASP.NET runtime environment, ASP.NET MVC makes developing Web apps a significantly different experience from using Web Forms. It uses a Web-oriented variation of the MVC pattern, and version 2.0 works with both Visual Studio 2008/.NET 3.5 and Visual Studio 2010/.NET 4.

ASP.NET MVC programs also use controllers and views, but you have to decide how to pass data to the view and expose your middle tier to the controllers. Each request is resolved by invoking a method on a controller class. No postbacks are required to service user requests and no viewstate is required to save the state of the page. Finally, server controls aren't necessary to produce HTML. However, ASP.NET MVC is still based on handling HTTP requests, except that the URL string is treated differently, and any resulting action is expressed by developers using methods on controller classes instead of postbacks.

In ASP.NET MVC, all incoming requests are channeled through a single component -- the MVC HTTP handler -- in a front controller approach. It contains the logic that parses the URL and decides which controller will service the request. The controller is a plain class with public methods; each method executes a task following a user action and subsequent HTTP request.

Page Controller and Front Controller..

The big change in ASP.NET MVC from ASP.NET is that a URL indicates an action to take, not a file to process. Each URL contains routing information for the front controller to identify the target controller. Set in the root directory's global.asax application file, mapping rules are an important part of the application. You organize the application around a few controller classes each with a set of methods. Action and production of the response are distinct steps that distinct subsystems take care of. This provides true separation of concerns because processing logic and generating responses are distinct components.

Improved testability follows from SoC and also from a design change of the MVC HTTP handler. ASP.NET intrinsic objects such as Request, Response, Session, and HttpContext are abstracted to interfaces, and the handler uses them only through the interface. This means that base classes for these objects are available. Full testability is guaranteed and doesn't require you to spin up the whole ASP.NET runtime.

Finally, ASP.NET MVC is neither bound to server controls nor to other rendering technologies. It generates responses through an object that implements a given contract -- the IViewEngine interface. The default view engine supports the familiar ASPX syntax and server controls. Any view engine you plug in may provide its own syntax for the view and could use any markup syntax. Subsequently, as a developer, you're given all the tools you need to gain the level of control over HTML.

Control over HTML: A Wider Perspective

One of the arguments often made to contrast ASP.NET MVC and Web Forms is that the former gains you much more control over the generated HTML markup. Honestly, this statement is hard to prove wrong. However, some considerations apply that may shed a different light over classic ASP.NET.

ASP.NET server controls are great and fast, but you can hardly control (and fix) the markup they produce. Nothing, but really nothing prevents you from writing classic ASP.NET pages using plain HTML elements and code blocks. If you really do so, you automatically get total control over the markup that your page outputs.

However, if you write an ASP.NET page without using server controls you lose the benefits (and niceties) of postback events and the overall Web Forms model. In classic ASP.NET, programming without server controls and postback events just means hitting the metal; not simply getting closer to it. ASP.NET MVC has a more flexible architecture for rendering and provides ad hoc tools for simplifying and smoothing HTML generation, less powerful than server controls, but also much less obtrusive.

ASP.NET MVC 2 just blinks at improving a lot in this area by providing a new family of HTML helpers that support templates and are, in a way, closer to server controls in terms of programming power but still less obtrusive.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.