Scott Guthrie announces ASP.NET MVC framework at Alt.Net Conf

Scott Guthrie announces ASP.NET MVC framework at Alt.Net Conf

 

Scott Guthrie proposed a topic at the Alt.Net Conference today, and the topic was an overview of the MVC Framework his team is working on.  His topic is actually the first timeslot of the conference at 9:30am tomorrow morning.  Just about everyone showed interest, so I wouldn't be surprised to see most of the folks just listening.

Scott and I had supper after the opening, and I received a personal demo of the prototype.  First, here are some of the goals:

• Natively support TDD model for controllers.
• Provide ASPX (without viewstate or postbacks) as a view engine
• Provide a hook for other view engines from MonoRail, etc.
• Support IoC containers for controller creation and DI on the controllers
• Provide complete control over URLs and navigation
• Be pluggable throughout
• Separation of concerns
• Integrate nicely within ASP.NET
• Support static as well as dynamic languages
  

I'm sure I missed some of the goals, and more people will blog their takeaways since this all is public information.

The first question might be: Is webforms going away?  Do I have to rewrite my web applications?  Some people might wish, but no.  Both models will be supported and even be supported within the same web application.  I, for one, after seeing this, think it is very good, and my company will be recommending it to our clients.

We might get a public CTP by the end of the year, and it will be released in a similar fashion as ASP.NET AJAX was, as an add-on after the Visual Studio 2008 release some time next year.

URLs

The default URL scheme will look something like this:

/<RouteName>/<Action>/<Param1>/<Param2>

where RouteName is configured to map to SomeController.  Multiple routes can map to the same controller for the purpose of providing more URLs (think SEO).

The developer can completely override the URL processing also by providing an implementation of an interface. 

Controllers

Controllers will inherit from a base class by default, but it doesn't hinder unit testing, and it's not even required.  I'll probably use the option of implementing the IController interface instead and creating a controller factory to support controller creation using my IoC container of choice (currently StructureMap).  In this manner, I implement an interface with one method that accepts IHttpContext (yep, we have an interface now), and RouteData, a simple DTO that includes the action and parameters for the web request (parsed from the URL scheme you are using).

Views

Like I said before, NVelocity, Brail, etc can be bolted on as view engines, and ASPX is provided as a view engine (the only thing that has been changed is that the code-behind will inherit from ViewPage as opposed to the current Page).  Controllers can either using IViewEngine (I think that's the name) to request a view by name (key) or using a helper method on the optional controller base class RenderView(string, viewData).  The default model uses a DTO for the objects passed to the view, so it is similar to MonoRail's property bag except it's a strongly-typed DTO (using generics for that), so when you rename stuff with Resharper, you don't have to worry about any string literals lying around.

My impressions

I first saw the early prototype in March of this year, and I was encouraged.  I was able to give some early feedback, which has already been encorporated into the product.  I'm not one to promote a Microsoft offering just because it's there (I have never recommended the use of MSTest over NUnit, for instance), but I will say this: As soon as I can get my hands on a build, I will be building something with it.  I am very encouraged by this, and I think they are going in the right direction.  While they have chosen a model to use with demos, they have broken down the walls.  Interfaces abound, and none of it is sealed.  I will start by swapping out the controller factory so I can get my IoC container in the mix, but it's easy to do.  For testing, there is no coupling of the controller.  The views are decoupled.  The httpcontext is decoupled with the new IHttpContext interface.  The actions are simple public methods with an attribute attached to them ([ControllerAction], I think).

Isn't it just like MonoRail?

Someone using MonoRail for more serious project than me can comment more intelligently, but here goes.  MonoRail is MVC.  This is MVC, so yes, it's very similar but different.  This gives us a controller that executes before a view ever comes into play, and it simplifies ASPX as a view engine by getting rid of viewstate and server-side postbacks with the event lifecycle.  That's about it.  MonoRail is much more.  MonoRail has tight integration with Windsor, ActiveRecord and several view engines.  MonoRail is more than just the MVC part.  I wouldn't be surprised if MonoRail were refactored to take advantage of the ASP.NET MVC HttpHandler just as a means to reduce the codebase a bit.  I think it would be a very easy move, and it would probably encourage MonoRail adoption (even beyond its current popularity).