My Blog Rewritten Using ASP.NET MVC

I decided it was time to rewrite my blog software using MVC. After watching the PDC 2008 MVC presentations I took a leap of faith and installed the beta. The good news is that without having a clue about what I was doing, I was able to complete the rewrite in about 10 hours. The blog is a complete functional replacement of the old ASP.NET version, I still run them side by side on my development box.

The only important issue that I haven't completely resolved is how I should handle caching. Page and control caching directives really aren't the way to go (I'm not even sure page/control caching would work given the way the views are constructed), but I'm not sure what the best alternative is when living in MVC . For now, I'm caching in the controllers using a common dependency that is triggered whenever there's an update to the blog (new/update post or a comment). Basically, I'll just have the view/page recreate the page and stay out of the database; and, since the database access was the primary performance bottleneck I'm pretty comfortable with solution. More about this later.

Other lessons and random thoughts:

• Don't skimp on studying the routing mechanism and fully understanding how it works. All of the problems I had doing the port were related to not knowing what the heck I was doing with routing. Definitely check out this route debugging tool from Phil Haack.
• It really pays to have an existing Domain Model in place. Most of the code I wrote for MVC was in the UI, the controllers were just simple calls to my domain service layer. I think I tweaked only a few lines in my DAL and domain model projects.
• I can really see how the recommended directory structure might break down for large applications. This Areas Post by Phil Haack might address that.
• On a similar note, creating a widget/mashup like structure was really tricky. In my blog the bottom footer contains a bunch of stuff that needs to be populated for each page. My first attempt was to just stick the view data into each controller, knowing that I'd find a better solution later. Here's a great post Steve Sanderson the got me where I needed to go. Ideally, I'd like to establish multiple sub controllers when I setup the routes... or maybe not. Now that I'm done this seems like the biggest hole in MVC, there really needs to be a way to structure a "page" from pieces rather than a single monolithic controller.
• Having (almost) complete control of the generated HTML is a great. No more trying to reverse engineer an ASP.NET server control to see why some sort of HTML was generated and trying to figure out how to fix it up.
• I think I read something about having the option for different view engines. This would allow me to get to the last mile, which is the white space in the ASP.NET page compiled messing things up.
• Using jQuery without having to deal with mangled HTML element id's is a joy.
• Forms handling is really straight forward (especially multiple forms per page). My hunch is that if you were used to the early days of web application development you'll like this way of dealing with forms; if, on the other hand, you started using WebForms in ASP.NET then you might find this model a little primitive.
• Goodbye and good riddance to ViewState.

I guess I'll see how it goes before passing final judgement.