Practical ASP.NET
ASP.NET MVC for the ASP.NET Programmer
Peter begins a series on educating traditional ASP.NET developers in the latest version of ASP.NET MVC. But first he looks at why he is not an ASP.NET MVC developer.
I'm an ASP.NET developer with only a passing interest, right now, in ASP.NET Model-View-Controller (MVC). I don't even have a good feel for what the adoption of ASP.NET MVC is like -- though I do know that bookings for Learning Tree's ASP.NET MVC course are creeping up to match the bookings for the ASP.NET course that I wrote for the company.
But if you're wondering what ASP.NET MVC is and whether you should be moving to it (i.e. assuming that you aren't currently using ASP.NET MVC) then this column and the next three are for you: An introduction to ASP.NET MVC for the (traditional?) ASP.NET programmer.
There are, as near as I can tell, three benefits to ASP.NET MVC. First, it gives you more control over the HTML being generated. This is a low value benefit to me as I count on hiring or partnering with people who have deep knowledge of HTML and CSS. The contribution that I make to my clients is expertise in application development, which is a full time job. ASP.NET development is one part of the package that I provide (the other components being database design, UI design, middle-tier business object modeling/implementation and SOA design).
The second benefit is, however, high on my list of value-added benefits: Test Driven Development (TDD). Testing an ASP.NET page is a labor intensive activity because someone has to write up a test plan and then sit in front of a computer interacting with a page to determine if the page behaves properly. I try to move as much logic as possible out of the page into my middle-tier business object in order to automate as much testing as possible, but inevitably my ASP.NET pages end up with some code that has to be validated. Indeed, any changes made to the business objects called from the ASP.NET page would require re-executing the tests on the ASP.NET pages that use those objects.
In ASP.NET MVC, the goal is to create a set of objects that manipulate the UI (the View) but can be tested from other code independently of the View. The View itself is either so spectacularly stupid that it's inconceivable that it could fail and so doesn't need testing, or can itself have much of its testing done in some automated fashion.
The third benefit is the "separation of concerns" object and is tied to the previous one: since the View is separated from the rest of the objects manipulating the presentation layer, it's conceivable that one View could be swapped out and replaced with another View (replacing a View page aimed at a Web browser with a View aimed at a mobile device or a Windows Form front end, for instance). My guess is that this is only possible by using a very smart View that would take advantage of the new environment or delivering a new View that fails to take advantage of the new View's environment. A smart View violates the benefit of TDD and a dumb View would just annoy users.
There are other benefits. It's likely that the ASP.NET MVC paradigm better supports code generation at the application level so, if you're generating applications (read: Dynamic Data) you'll find it easier to create ASP.NET MVC applications than ASP.NET applications. Not much of a benefit for a full-time developer, though, who is hired by people who don't want their application generated automatically.
ASP.NET MVC also makes extensive use of routing, which I've praised before (for .NET 3.5+ here and for .NET 4 here), but can also be used with ASP.NET.
This sounds unnecessarily negative. While I think that the idea of swapping out Views is foolish with the present technologies, that doesn't mean it will always be so. People who do want control over HTML will value that. And, quite frankly, supporting TDD more effectively is a compelling argument for me, all by itself.
So why haven't I moved to ASP.NET MVC if TDD means so much to me? Because, in my experience with the first iteration of ASP.NET MVC, I found that creating applications was so labor intensive that whatever benefits I got from using TDD were wiped out by how much less productive I was going to be in this environment. There's another reason that will become cleared in the next column: the ASP.NET MVC model matches well to a Service Oriented Architecture.
But that was then, and this is now. There's a new version of ASP.NET MVC out and I'd be an idiot not to look at it. So that's what the next three columns will be doing: educating ASP.NET developers on ASP.NET MVC 2.
About the Author
Peter Vogel is a principal in PH&V Information Services, specializing in ASP.NET development with expertise in SOA, XML, database, and user interface design. His most recent book ("rtfm*") is on writing effective user manuals, and his blog on technical writing can be found at rtfmphvis.blogspot.com.