RTM’d today: Programming Microsoft ASP.NET MVC

We’re very pleased to announce that Dino Esposito’s latest book, Programming Microsoft ASP.NET MVC, has shipped to the printer!

Covering ASP.NET MVC 2 and Visual Studio 2010, Dino’s book will help you understand how and when to use this programming model as an alternative to Web Forms—to gain full control of HTML, simplify testing and extensibility, and design better Web sites and experiences. As always, Esposito provides the detailed, insightful guidance and illustrative code samples you need to get productive quickly.

Dino’s book will be available via online retailers around May 15. In the meantime, here’s more information about the book, including Dino’s personal road of discovery regarding MVC:

Contents at a Glance

Part I   The Programming Paradigm

1   Goals of ASP.NET MVC and Motivation
for Its Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2   The Runtime Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3   The MVC Pattern and Beyond. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Part II   The Core of ASP.NET MVC

4   Inside Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5   Inside Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
6   Inside Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

Part III   Programming Features

7   Data Entry in ASP.NET MVC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
8   The ASP.NET MVC Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . 355
9   AJAX Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
10   Testability and Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
11   Customizing ASP.NET MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

Introduction

Get your facts first, and then you can distort them as much as you please.
—Mark Twain

In the spring of 2006, I had the privilege of taking a very early look at what would eventually
become ASP.NET MVC. Scott Guthrie of Microsoft arranged a personal demo just for me
backstage at the DevConnections conference in balmy Nice, France. At the time, I had just
started playing with ASP.NET Web Forms and the Model-View-Presenter (MVP) pattern.
I expected to see the usual great set of designers to automatically define models, controllers,
and views. Instead, I was surprised to see a brand-new application model being worked out
on top of the same ASP.NET runtime. (Note that what I saw at that time was at best a distant
relative to what you know today as ASP.NET MVC, but the key facts were already visible.)

Not that getting rid of the postback model looked like a bad thing to me, but frankly the
idea of changing the programming model quite significantly didn’t impress me that much.
The combination of ASP.NET Web Forms and MVP seemed to me a more natural and less
disruptive way to achieve separation of concerns and overall better quality code. Scott
pointed me to a couple of team members that I pinged a few times during the summer
for more information and newer builds. But nothing happened. Instead, in the summer of
2006 all the excitement being generated was for the upcoming ASP.NET AJAX Extensions
(remember Atlas?). Overwhelmed by the AJAX bandwagon, I gravitated to this clear
sentiment: that funky ASP.NET MVC thing was just a proof of concept, a good-for-fun project.
So I removed it from my mind.

In October 2007, I was in Malaga, Spain, to make a presentation to a local user group. During
a break, my friend Hadi Hariri asked my opinion about the just-released, first preview of
ASP.NET MVC.

ASP.NET what?

I had a look at the bits, and a few weeks later I even wrote one of the very first articles about
ASP.NET MVC for the DotNetSlackers Web site. The article is still there (and mostly valid) at
http://www.dotnetslackers.com/articles/aspnet/AnArchitecturalViewOfTheASPNETMVCFramework.aspx.
The taste of ASP.NET MVC was bittersweet for me. Overall, ASP.NET MVC seemed like
an entire step backwards and I couldn’t see the point of it. And I asked the same question so
many times:

When is this going to be really (and tangibly) better than ASP.NET Web Forms?

This is the fundamental question. And it is still largely unanswered, to the point that I suspect
that it can’t really have an answer.

Although it’s based on the same runtime environment, ASP.NET MVC is significantly different
from ASP.NET Web Forms. It supports a radically different pattern—MVC (actually the special
flavor of MVC known as Model2) rather than a pure Page Controller—and was designed with
a radically different set of goals—testability, extensibility, and closeness-to-the-metal of both
the Web and ASP.NET runtime.

It doesn’t matter what kind of software professional you are, when it comes to choosing the
platform for a new .NET Web application you feel like you are at a crossroads. You know you
have to choose, and you look around for guidance. You see pros and cons on both sides,
and you can hardly see—clearly and tangibly—what’s the right way to go. For this reason,
the core question—should we use ASP.NET Web Forms or ASP.NET MVC—often ends up
being an endless and pointless religious discussion where all parties push their own vision
and scream louder with the gathering force of their conviction.

In the end, the correct answer is that it depends. In the end, the choice is really like Microsoft
describes it: car vs. motorcycle or automatic vs. manual.

This leads to a new and largely unspoken question: Did we really need a second option?
Wouldn’t it have been better for us if Microsoft detected the signs of age of Web Forms
and worked as hard as they worked on ASP.NET MVC to improve that, sticking to just one
framework?

Aren’t two options always better than one? Sure, but two options imply a choice. And
a choice implies information, education, and responsibility. Here’s where this book
hopefully fits in.

ASP.NET MVC and Web Forms

Until late 2008, I was happy enough with Web Forms. I did recognize its weak points and was
able to work around them nicely with discipline and systematic application of design
principles. In the beginning, ASP.NET MVC was enthusiastically received by a relatively small
segment of the community, but one that was screaming loudly and posting a lot. Even
though I’ve never been a member of the ALT.NET community, I’m still constantly keeping
an eye out for any better ways of doing my tasks. So I started to explore the ASP.NET MVC
architecture and tried to understand its potential, while constantly trying to envision concrete
business scenarios in which to employ it. I did this for about a year.

What did I learn?

Technically speaking, ASP.NET MVC is far superior to Web Forms. This is because it’s
newer and was designed around an alternate and more modern set of principles and
patterns. Is this sufficient reason for you to switch to it? In my opinion, it isn’t. ASP.NET
MVC is an excellent choice from the perspective of developers, but that fact alone doesn’t
automatically translate into a tangible benefit for the customer and the project. Moreover,
ASP.NET MVC is much less forgiving than Web Forms and requires training, or at least
self-training.

In 10 years of using Web Forms, I’ve seen many professionals with limited programming skills
produce effective Web front ends using data-bound controls and a bit of Microsoft Visual
Basic. This will not happen with ASP.NET MVC. Worse yet, if you start writing ASP.NET MVC
code taking the learn-as-you-go approach that worked for many with Web Forms, you will
surely cook up great examples of much hated spaghetti code.

So learning ASP.NET MVC makes you a better developer, but it has a cost. Who’s supposed
to pay for that? Your customer? Your company? You, yourself? How would you justify to
a project manager the extra training costs for just using ASP.NET MVC? You can try, but the
natural objection is this: “OK, but where’s my return? Can’t we take this project home by
simply using Web Forms, which we already know through and through?”

In the end, picking ASP.NET MVC over Web Forms is a matter of preference and attitude,
or it’s a matter of dealing with some nonfunctional requirements. In the first case, you don’t
have extra costs because it can be assumed you know your stuff very well. The second case,
instead, introduces the only scenario I can think of where ASP.NET MVC is a clear winner.
How can you fulfill requirements such as strict accessibility, adherence to Web standards,
XHTML, theme-ability, cross-browser experience, and rich AJAX capabilities?

These requirements lead to the necessity of exercising strict control over the markup emitted
for each page. This is an area where ASP.NET MVC is incomparably better than Web Forms,
even when you take into consideration Microsoft’s latest improvements to the ASP.NET 4
framework and your own programming self-discipline.

Every other argument being presented as a plus of ASP.NET MVC—such as testability,
separation of concerns, extensibility, and the like—is just a plus of the framework, not
a breakthrough for the project. By the way, even though in the .NET space we seem to have
discovered testability only a few years ago, it has been listed as a fundamental attribute of
software in the ISO/IEC 9126 paper since 1991. (For more information, have a look at
http://en.wikipedia.org/wiki/ISO_9126.)

Who Is This Book For?

As explained in great detail in Chapter 1, “Goal of ASP.NET MVC and Motivation for Its
Development,” ASP.NET Web Forms is showing the signs of age. And ASP.NET MVC is an
excellent (although still incomplete) replacement. My guess—my humble, two-cent guess—is
that in a couple of years (and in a couple of versions) ASP.NET MVC will offer the same level
of productivity as Web Forms—either because of framework enhancements or because of
even more powerful tooling. At that point, you will have two options that are equivalent
functionally and in terms of productivity. But one of them (ASP.NET MVC) can help you write
better code, faster. This may not be the case today with ASP.NET MVC 2, but it likely will be
the case with ASP.NET MVC 3 or 4.

I don’t think that ASP.NET Web Forms will be dismissed very soon. For example, rumors
suggest that ASP.NET Web Forms will move decidedly toward increasing testability in
version 5 through the introduction of some MVP support. We’ll see, but as I see things
ASP.NET MVC is and will remain far superior technically.

Although pushing a team to use ASP.NET MVC today on a project might be an arguable
choice, pushing it within a software company isn’t an arguable choice at all. Having a deep
understanding of ASP.NET MVC makes you a better developer. ASP.NET MVC is easy to pick up
for junior developers who are just out of school, even though it could be harder for experienced
Web Forms developers to learn. This book assumes you have knowledge of Web Forms
programming as it explains how ASP.NET MVC works and how to use it effectively.

My experience shows that too many Web Forms developers built their expertise by trial
and error. ASP.NET MVC requires a sort of reset, and you know that after you reboot your
machine it normally runs faster. But this personal reboot may take a bit of effort. Start
today with ASP.NET MVC, even in parallel with current Web Forms projects. You’ll see the
difference, understand the basic facts of Web development, and soon be ready for writing
better code with both Web Forms and ASP.NET MVC.