I have spent the past couple weeks holed up in a cave building a web site using the latest ASP.NET MVC framework. I am behind on blogging, responding to emails, and keeping up with my RSS feeds. I am making good progress with ASP.NET's MVC framework and enjoying the development experience, despite the occasional beta blip.

I started developing a site using the MVC Preview 2 source. Two weeks in, I pulled the latest MvcContrib project, and a few days ago I upgraded again to the MVC Preview 3 source. Like anyone using beta software, I have spent some time swearing at my screen, but overall, I am pleased with the MVC framework. After returning from vacation, I now find that I am one more release behind on my MvcContrib binaries.

As I began developing with the MVC framework, the similarities I was seeing with Castle's MonoRail MVC were numerous and reassuring. I felt like I could hit the ground running with previous MVC knowledge. The sample MVC application right out of the box is functional and a helpful place to start familiarizing and education oneself with the new framework. For those tools and features that are not built into the framework at this point, I found the MvcContrib project to be helpful in my development.

It seemed like with each day of development I would discover something new, cool, or exciting, and I wanted to share it on this blog. As I started down the path of writing a blog entry, I procrastinated each time thinking, "let me just get through this one issue first and then I will blog." That approach snowballed tremendously. With each hurdle I had to surpass, there was another release I had to install. Of course, I did not have to install any of these updates, but I did thinking they would be trivial. In some cases they were, and in some they were not. My point - there is a great deal of change and development constantly occurring on the MVC framework and other tools supporting it. Expect this rate of change while the framework is maturing. Sometimes it is frustrating, but there is great support on the ASP.NET/MVC forums as well as MvcContrib.

Why do I like it?

MVC promotes a cleaner separation of concerns. Since I am used to developing in ASP.NET and trying to adhere to a loosely defined MVP pattern, this MVC framework mitigates some of the frustrations of having to enforce the pattern as well as SoC.

Testability is build into the framework. When creating a new project, there is an option to create a test project to accompany it.

I can create a web site quickly and cleanly. As I add a new page (view), I have a distinct controller and view for it. Unlike MVP implemented in ASP.NET, I do not have to enforce my controller-view separation, it is done for me.

I am able to use use more than one view engine easily. I am tired of using the ASP.NET view engine. While one can roll their own view engine flavor, MvcContrib provides support for a few out of the box. I can free myself of having to use ASPX pages, ASCX user controls, and their code-behind files.

I prefer using the NVelocity view engine. I prefer the more simple HTML view of NVelocity. My customers enjoy it as well, and they do not have to concern themselves with ASP syntax. They will have to learn a few tricks with NVelocity, but nothing that is not intuitive as it is.

Extensible source. I have been able to add custom support to provide overrides and additional functionality to the framework as I need it.

Community support. The MvcContrib project helps make development with MVC easier. Use their view engines and IoC container support. Know of some functionality that is not available, add it.

Pitfalls

IIS 6 and URL rewriting. While it is possible to get the nice URL rewriting to work with IIS 6, ISAPI filters, and extension mappings. It is a PITA. I am in the process of upgrading my customer's environment to use IIS 7. Today, their URL contains the ".mvc" string, such as, <domainName>/home.mvc, or <domainName>/account.mvc/login. I suggest having IIS 7 available.

Ajax framework. I am still waiting on a good Ajax framework to be included. The one MonoRail includes is nice. As for now, I am using jQuery and developing my own. Hmmm, maybe this functionality could be added to the MvcContrib project, and maybe instead of limiting it to jQuery, I could abstract it to enable other Ajax providers. We'll see what time permits.

Third party controls like Telerik, Infragistics, et alia. Rich datagrids, tree controls, and other controls that rely on view state and postbacks. I expect support will come around for these.

I tried the NHaml view engine, a .NET implementation of the Rails Haml view engine. My NHaml default layout (master page) was generating runtime errors because I was not use the proper spacing of two characters. Seriously? Two spaces? Who cares. I moved on to try Brail.

I have been pleased thus far. Thank you to the ASP.NET MVC team and the contributors to the MvcContrib project. Keep up the great work.