The ASP.Net MVC Option

In previous posts, I talked about the ASP.Net Postback Problem and using updatepanels and partial postbacks as a potential method to solve those problems. There's another solution, which may fit better with those like myself (who are moving into ASP.Net from a background with the LAMP stack): ASP.Net MVC

In short, ASP.Net MVC provides mechanism to follow the Model, View, Controller design pattern in ASP.Net development. For many, MVC is a more natural and cleaner way to produce and maintain code. In the ASP.Net realm, it also provides many benefits that address the issues I've railed against in traditional ASP.Net Webforms Applications. Specifically, discussions on StackOverflow repeatedly reference improvements in:

• Separation of concerns (SoC) • From a technical standpoint, the organization of code within MVC is very clean, organized and granular, making it easier (hopefully) for a web application to scale in terms of functionality. Promotes great design from a development standpoint.
• Easier integration with client side tools (rich user interface tools) • More than ever, web applications are increasingly becoming as rich as the applications you see on your desktops. With MVC, it gives you the ability to integrate with such toolkits (such as jQuery) with greater ease and more seamless than in Web Forms.
• Search Engine Optimization (SEO) Friendly / Stateless • URL's are more friendly to search engines (i.e. mywebapplication.com/users/ 1 - retrieve user with an ID of 1 vs mywebapplication/users/getuser.aspx (id passed in session)). Similarly, since MVC is stateless, this removes the headache of users who spawn multiple web browsers from the same window (session collisions). Along those same lines, MVC adheres to the stateless web protocol rather than 'battling' against it.
• Works well with developers who need high degree of control • Many controls in ASP.NET web forms automatically generate much of the raw HTML you see when an page is rendered. This can cause headaches for developers. With MVC, it lends itself better towards having complete control with what is rendered and there are no surprises. Even more important, is that the HTML forms typically are much smaller than the Web forms which can equate to a performance boost - something to seriously consider.
• Test Driven Development (TDD) • With MVC, you can more easily create tests for the web side of things. An additional layer of testing will provide yet another layer of defense against unexpected behavior.

For my part, SoC and TDD are minor issues, at best. I subscribe heavily to Joel Spolsky's idea that it is very easy for Test Driven Development to cross the line into excessive wheel-spinning. I test my products thoroughly, but to add the step of full blown TDD and unit-tests-for-everything crosses the line into more time spent than I can typically justify. I'd rather be getting stuff done.

That said, the other three benefits are great. They seem to perfectly address the parts of ASP.Net development which have thus far led to the most frustration for me.

I'm approaching the point of wrapping up my current project. When that is final (e.g. next week), I will be taking some time to do some learning. At the top of my list is to spend some time working with 1) UpdatePanels & Partial Postbacks and 2) ASP.Net MVC. Once I've played more with each, I'll report back here with my thoughts.