I have been reading Scott Guthrie's and Scott Hanselman's posts on ASP.NET MVC and it got me thinking.  Here are a few points that I think would be interesting to discuss further:

1. Quite soon after I started developing Business Web Applications, circa 2001, I came to the conclusion that the programming model offered at the time did not suite a Business Application so well.  HTML, then ASP, and finally ASP.NET, had serious shortcomings as far as developing Business Applications.  This is not to say that it was not possible to develop them.
   
   The programming model that came to my mind was as follows:
   1. UI happens in HTML in the Browser (no back and forth postbacks for updating the UI).
   2. Navigation happens in the Browser (no need to go to the server to navigate to a new page).
   3. You only go to the server for Business Processing and Data. (Well, this is kind of like AJAX)
      
      Wait a second; now that I think of it, this model reminds me of something!  Hmmm...
      This looks a lot like Smart Client Application, or Silverlight, but developed in HTML.  Wow, what do you know, the programming models for Business Applications are merging ...
   
   Of course, none of the tools of the time supported the model I had in mind very well.
   
   In my opinion, ASP.NET MVC takes a huge step in the right direction.  However, it is not quite there yet. 
   For instance, regarding Navigation, when you initiate a POST or a GET from the browser, it is the decision of the browser where to put the returning HTML.  This does not seem to sit so well with the notion that the ASP.NET MVC Controller decides which View to render on the server.
   Furthermore, if your navigation is done from the server by Rendering a new View, does this mean that we will go back to whole pages refreshing every time you go to the server?  I thought we were on the verge of resolving this problem with AJAX.
2. ASP.NET MVC is NOT ASP.NET!  In all the blog posts and presentations I saw coming out from Microsoft about ASP.NET MVC they make a point to say that it is an extension on top of ASP.NET and that the two models will play well together.  I think that in reality, this is not the case.  If the ASP.NET MVC programming model catches on, it will completely deprecate ASP.NET.  ASP.NET is about the controls and their event handling model.  But the ASP.NET controls are a no no in ASP.NET MVC because no Post Back is allowed (or supported).  This is just the same as the fact that you can still use ASP style programming in your ASP.NET pages, however, no one in their right mind does.
3. ASP.NET MVC does a great job in regard to "Separation Of Concerns".  However, when I originally learned about the MVC Pattern it was suggested that an implementation would allow sharing the business part of the application between Web and WinForms based UI implementations of the same application.  I am not sure ASP.NET MVC is suitable for this (or was intended to do this).  So, this brings up a couple of questions:
1. Is it possible to share the business part of the application between a WinForms implementation and a Web implementation of the UI?  How much customization would that require?
2. How much further does the model need to be changed to support this inherently?

In summary, I would l to say that these are just my thoughts.  I hope that they will contribute to a fruitful discussion and to a better implementation.

 ---

Adar Wesley

Hey Adar, those are some good thoughts.

1. You're right: ASP.NET MVC is focused on generating complete HTML pages so the web browser can navigate through them in a traditional way. As you predict, this model will likely fade away eventually (see Google Web Toolkit or client-side MVC approaches) but for the next few years at least, for interoperability and meeting-the-public's-expectations reasons, we still need to support the traditional web page model.

2. Naming isn't clear yet. Who knows what ASP.NET MVC will be called when it gets to a final release? Also, it is built on ASP.NET, and shares a lot of common infrastructure, including the WebForms engine, so you can't say it's "not" ASP.NET. 

3.  You can definitely share the "model" portion of your MVC triad across web and desktop apps without any code changes. Almost all your business rules should be in the model. You could conceivably try to share controller code, but there shouldn't be much business logic there, and it's probably too hard to be worth it. You definitely can't share the Views portion - WebForms views are all about the web. 

I think ASP.NET MVC strengthens AJAX development. ASP.NET MVC facilitates a RESTful (or at least RESTish) approach to writing your application, great for integration of all clients, including browsers. Typically your site will be a collection of pages and the interactive AJAX applications will reside on specific pages, so I don't see that as being an obstacle. An entire site in one primary request typically is not what most sites will look like (and there are good buzzwords reasons for this - semantic web, search engine optimization), but MVC affects that approach little. Good components will take advantage of the intuitive nature of MVC to provide strong AJAX support. I suspect the developers have this in mind, and I wouldn't be surprised to see something analogous to the ScriptManager to embed proxies to WCF services. The solution that immediately comes to mind is simply requesting views from client script, which is the subject of other topics and a number of blog posts.

A hack, maybe, but this is an example, assuming your ViewData is consumable by WCF:
 

public abstract class SerializedViewPage<T> : ViewPage<T>
{
	public override void RenderView(ViewContext viewContext)
	{
		if (viewContext.HttpContext.Request.QueryString["format"] == "json")
		{
			viewContext.HttpContext.Response.ContentType = "application/json";
			var serializer = new DataContractJsonSerializer(typeof(T));
			serializer.WriteObject(HttpContext.Current.Response.OutputStream, ViewData);
		}
		else if (viewContext.HttpContext.Request.QueryString["format"] == "xml")
		{
			viewContext.HttpContext.Response.ContentType = "application/xml";
			var serializer = new DataContractSerializer(typeof(T));
			serializer.WriteObject(HttpContext.Current.Response.OutputStream, ViewData);
		}
		else
		{
			base.RenderView(viewContext);
		}
	}
}