Obviously there are a lot of very interesting technologies out there that should help every developer to create great .NET-based web applications. Unfortunately with .NET growing faster with every year, the rising number of conceptually overlapping technologies sometimes creates confusion and insecurity, especially in the beginners developer community. "What .NET framework should I use?" is a common question these days.

Coming from the Java EE world I remember a time a couple of years ago when we were developing with different Java web frameworks. I worked a lot with JSF and Spring Web MVC, but we also used Struts, Beehive, Tapestry, Cocoon and some other in different projects. Whenever we started a project using one particular framework, we usually had to stick with it or we had to create a completely different application root and development style when we decided to add another framework to the toolset that could fulfill the requirement with more elegance and effectiveness than the primary framework.

When I look back at that time now, I see the need for guidance in our world and I see that we have to make good choices in our technical strategy. I will try to provide this guidance in this article, but I invite you to share your thoughts and views with me. First of all, I have to say that I have always been a fan of a very "clean" development style. "It runs" is not enough for me.

Having said that, I have to admit that ASP.NET WebForms aren't really the cleanest way to develop web applications - or better, most people are somewhat lazy and take the path of the least resistance, so they use WebForms in a "dirty" way: They don't use data binding (either native ASP.NET or Spring.NET), events and customer controls appropriately. Instead they directly assign values to properties in code-behind files at several states of the page lifecycle and wonder why they get Spaghetti code in their Page_Load and Page_PreRender methods. Sometimes they even get strange results because they lack the knowledge of the page lifecycle in WebForms. Well, of course there is a better way, but because the WebForms model is more or less a "conceptual porting" of the WinForms model to the web and because it tries to support a development style that is based on state by emulating several desktop-like environmental conditions, the root of the problem lies in the underlying architecture of the framework.

The Sitecore development model uses several features of ASP.NET WebForms. But by taking a closer look at the system, it actually becomes clear that there is no real dependency between Sitecore and the WebForms model - it is just one way to create Sitecore renderings. I'm pretty sure that Sitecore will work very well with ASP.NET MVC in the near future, because it is in itself an implementation of a FrontController pattern with different View engines. The most common ones (Web Controls, Sublayouts, XSLT renderings) happen to be based on the WebForms model.

(By the way, you could use XSLT without ASP.NET WebForms, but by just placing XSLT output in typical content zones of the website using Sitecore Web Controls, the definition of overall website design with standard HTML and WebForm tools is much easier.)

So, apparently being a Sitecore developer is a very good starting point for learning ASP.NET MVC. With ancestors like Struts and Ruby on Rails the whole approach of the Model-View-Controller pattern has been proven very useful in the last couple of years. ASP.NET MVC not only removes the curiosities that had to be introduced with the WebForms model to support the Postback mechanism and the event emulation, it also focuses much more on things like cross-page navigation, meaningful URLs and a better separation of concerns (routing, integration logic, presentation). Instead of trying to hide the way the web is really working and to replace it with a sometimes inconsistent and emulated desktop-like development model, it acknowledges that way and provides appropriate tools and helpers for developers to deal with request / response sequences.

As you can see, I like the way ASP.NET MVC is doing things and I also like the possibility to use some ASP.NET WebForms features "in the back".

So, what's wrong with the page / control model in ASP.NET WebForms? Nothing. Actually, the only thing we need to do is to shift it to a place where it works in a more natural way. Well, in my opinion, that place is the client. And that is exactly what the Microsoft AJAX Library is trying to do. So, why's that? First of all, the client has something that the Postback machanism can only simulate - the client has real state. Because of that, client-side events are really what they pretend to be: A way to respond to a actual user interaction directly without the need to "recreate" the whole state of the page first, perform the changes and then send it back to the client. Usually we need data to perform the operation that has just been triggered by a user, so what do we need to do now? Well, here is the revival of the good old client-server-architecture: We use WCF and client-side JavaScript proxies to communicate with the server and receive updated data structures directly. So instead of using slow UpdatePanels that complicate the whole Postback model further and create additional load on the client without reducing the work on the server, we let the server serve the data and our client update the user interface. We are not bonding an inconsistent framework with additional band-aids just because "it's so easy to use". We face the challenges of Web 2.0 and use our know how to create a responsive, well-designed Rich Internet Application by using client-side technology (like JavaScript with the Microsoft AJAX Library or Silverlight) for the user interface and server-side technology for cross-page navigation, initial response creation, business logic and the transformation of information.

So, what is the master way to go? Our future applications take the following approach: The first rendering of a webpage is done by Sitecore or ASP.NET MVC, sometimes using some ASP.NET controls in the back, ideally with DataBinding. After the initial page has been received by the client, we switch to "real" AJAX and use object-oriented JavaScript to create straight user interface logic using the Microsoft AJAX Library and communicate over Web Services with our WCF services on the server-side. There might be situations where it is appropriate to use partial rendering features of ASP.NET MVC, but ASP.NET WebForm pages with Postbacks and UpdatePanels are definitely in the past.