Dino Esposito: “ASP.NET MVC: Your Option and Your Peril”

Dino here. Imagine you spent the last three years in a dark cave hidden in the intricate labyrinth of some rainforest. And imagine you had no connectivity for all that time. Now you’re back and you can’t wait to put your hands on the freshly released version of Visual Studio. You used to be a Web developer and you knew quite a bit of Web Forms programming—let’s say you were a loyal reader of my past books. (Thank you!)

You open up Visual Studio 2010 and choose to create your first new Web project after three years—big surprise! You have now two options: ASP.NET Web Forms and ASP.NET MVC. It’s like getting a double (and largely unexpected) visit from the stork. You were waiting for one, and you get two. And, worse yet, you don’t know why two. Nor which is the one you want to choose.

By the way, you have to choose one flavor of ASP.NET for your next project.

The Microsoft official wording says that the choice is a matter of preference—like car vs. motorcycle or perhaps manual vs. automatic. There are moments, I believe, in which having two choices is bad because it forces you to choose in a situation in which you can’t see one option as clearly better than the other. Two options just mean you have to choose; but based on what?

The first CTP of ASP.NET MVC was released in the fall of 2007. I disregarded ASP.NET MVC for too long. I certainly was not an early adopter. It took some time and a lot of work, but I believe I got to know it from the inside. Well, let me then say that ASP.NET MVC is best (large) piece of code that I’ve seen in a long time.

It’s not perfect, but it is well done and far superior to Web Forms technically and architecturally. In my opinion, it really represents the way to go for most developers in the midterm.

Does this mean that Web Forms is at a dead end? I don’t think Microsoft will dismiss Web Forms anytime soon. I expect that Web Forms and ASP.NET MVC will stay side by side for a few more years, and probably—just a guess—for a couple of the next versions of Visual Studio. What should you do then? Enthusiastically embrace ASP.NET MVC? Or just ignore it and stick to Web Forms?

If you have time to learn—and I heartily recommend you manage to reserve yourself some of this very valuable time—I suggest you get the gist of ASP.NET MVC looking at its architecture, contrasting it to Web Forms, and trying to write sample applications. I don’t recommend you look into case studies or reference applications as your starting point. I suggest you start writing a small application of your own. Pick a small one and write from start to finishas best you can. Then stop and study and perhaps look into what others are doing. When you feel ready, make another attempt.

You’ll discover the power of ASP.NET MVC as you go. I started my exploration biased that ASP.NET MVC was not ideal for applications heavily based on data entry. But then I discovered the power of model binding that, combined with proper layering of the back-end code, makes it so effective to write even data entry applications. My conclusion, therefore, is that ASP.NET MVC is good for just about every type of Web application.

It’s probably premature to suggest today that the community will abandon Web Forms to embrace ASP.NET MVC. But the new ASP.NET MVC framework drives you toward better code. Don’t get me wrong: ASP.NET MVC doesn’t automagically make your code clean, elegant, and flexible. But it puts you on the right track and delivers an environment in which you can write testable code and practice seriously with unit testing. And get total control over the markup.

This is another quite debated point. At first sight, ASP.NET MVC seems to be a whole step backwards as far as productivity is concerned. What’s your definition of productivity? Being able to write 10 Web pages a day? I agree that if you take a quantity-based approach to measure productivity, ASP.NET MVC will lose the game with ASP.NET Web Forms. The “productivity” that the server control model guarantees is really hard to beat. But we are used to adding several days of maintenance and post-delivery debug to our counts for a project. This is largely due to the low quality of the code the Web Forms model allows us to write—most of the time.

Low quality is loss of money. The “apparent” speed (oops, productivity) is partly lost due to the extra work of post-delivery debug, optimization, fine-tuning, refactoring, and testing. An initial higher quality of code will take more time to get into production but will save extra work later.

Once you use it, you inevitably find out that ASP.NET MVC is highly productive—much more than Web Forms. Quick code of higher quality. It won’t happen on day 1, though, and it requires awareness and a bit of study. ASP.NET MVC propounds a quality-based approach to productivity.

You can’t use server controls? No worries. I confess that—having spent months of my life on server controls—I was very skeptical in the beginning. After completing the first long project, I can tell you that HTML and AJAX helpers are a great tool. I no longer feel the need for a declarative model. The real level of reusability you need most of the time targets small pieces of code—and those can be easily managed with helpers. For more sophisticated things, you can always buy a library of controls, from many vendors (SyncFusion, Telerik, and others).

Control over markup guarantees a solid cross-browser behavior with no need of using band-aids and tape to make it work.

ASP.NET MVC is different from Web Forms even though both run on the same runtime environment. It takes more time to learn and requires a bit of upfront work. I’ve seen many developers building applications successfully with Web Forms who have limited skills and just proceed by trial and error. This approach won’t work with ASP.NET MVC, I’m afraid.

But if you take some time to learn it, it will pay back quickly and abundantly. If you’re managing a team of developers, ASP.NET MVC is definitely a framework you want to learn about to make it your first choice for Web development. In the end, this is what I did in my company and with my developers.

You can still stick to Web Forms and ignore ASP.NET MVC, but if you choose to ignore it, make sure you have a good reason. If you choose to ignore it because you feel you don’t need it, well, do so at your own peril.

Programming Microsoft ASP.NET MVC covers the latest version of MVC (version 2) that also ships with Visual Studio 2010. It ranges from deep business and architectural analysis of why you should look at MVC up to the heights of programming controllers and views. The book ends with design considerations about the different flavors of data model you face, modeling the middle tier of an application, and the extensibility model of ASP.NET MVC. You will find also sections on Unity, AJAX, patterns, and testability.

Whatever your final decision about ASP.NET MVC, make sure you make it for a reason. Programming Microsoft ASP.NET MVC has been written by someone who opted for ASP.NET MVC with reason and who couldn’t be happier.

P.S. from Devon: Take a look at the full TOC and two sample chapters from Programming Microsoft ASP.NET MVC.