Building AgiliTrain: Part 1 - Why ASP.NET MVC

Url: https://AgiliTrain.com

I’ve spent the better part of six weeks building the new AgiliTrain website and its been quite a lot of fun. Of course if you have been reading this blog for long you know that I usually take a personal project like this as an opportunity to learning something new.  In this case I did three things I haven’t done on a personal project before:

• Use ASP.NET MVC (Beta)
• Use Oslo’s MSchema
• Use a Designer

I’ve been itching to use ASP.NET MVC on a project but until the beta arrived I didn’t want spend too much time with it.  Of course as you probably know, ASP.NET MVC released a RC yesterday so its pretty close to being done.  I am still on the Beta until they RTW (release to web) ASP.NET MVC.  Don’t want to retrofit it twice.

I’ve been thinking a lot about how I would characterize my experience with ASP.NET MVC. I recently was at a talk from Paul Lockwood (at the Atlanta .NET User Group) and he thought that it was two weeks of a steep learning curve then bliss.  That’s pretty close to my experience.  I thrashed for a couple of weeks wondering whether going back to WebForms would be faster…but I was patient.

I talk to some people about their fears of ASP.NET MVC and the big one I hear is lost of ViewState. I was never a fan of ViewState and was always perplexed that most projects used WebControls and not nearly enough HtmlControls. HTTP is stateless so in many many situations remaining stateless makes more sense.  Since the HTML controls were lighter weight I tended to use them much more often. That certainly makes my move to MVC easier as I am not bogged down by the loss of ViewState.

Another contention I hear is that ASP.NET MVC allows you to write code more like the web. This means doing a lot of AJAX and using jQuery (or Dojo, or whatever you want) as your UI layer. While that is interesting in a wide variety of scenarios…I don’t think PostBacks are as evil as we make them out to be. One of the problems with WebForms was that since it was tied to post-backs and sending back ViewState…those post-backs were always big.  For AgiliTrain I didn’t feel the need for a lot of wiz-bang.  I am just presenting materials and taking data (for registration and such). Very simple and doing that in simple HTML still appeals to me. In fact, the argument against simple post-backs is lost without ViewState. My Postbacks to the server are tiny because they simply contain mostly just the data users are entering.  I think the real evil was when post-backs were used as a replacement for event handling situations…the post-backs themselves weren’t the problem…the programming model was.

I did use jQuery in a couple of places where I needed rich behavior in the UI but that was the exception rather than the rule. I built a website not a web application.  If you’re building a web application, this is likely to be reversed. Building lots of interactivity and paging and such makes sense in that case…just not mine.

But why did I use ASP.NET MVC at all?  Was it because I wanted to learn a new technology or was it the best tool for the job? In my case both are true. I needed a site that is very SEO friendly and to do the kind of routing I wanted (like I did in my Wildermuth.com site) was harder than it should have been.  I wanted a better experience.  I also thought that since I was presenting information that is changing somewhat rapidly that I could develop it faster with ASP.NET MVC.  Not faster in the initial implementation (because I had to learn MVC) but faster to add new functionality as it required it.  I am not positive this is true but in the last few days I’ve been able to add new pieces of functionality to the site pretty easily. It feels a lot more modular than my other sites.

There were two big ah-ha moments for me in using ASP.NET MVC:

• When I was told to create models that contained the data for the view (instead of using my data model).
• When I integrated the designer’s wireframes into the project.

The first of these was big because I was using ViewData for everything and it felt like Session state again.  A big property bag of loosely typed data that I was hoping would work.

The second of these was a huge surprise as the MVC code was mostly clean HTML (no magic ClientID’s or controls) so that integrating was simple.

In the next couple of parts of this series I will delve deeper into how I built up the site using ASP.NET MVC and why I think its a great approach for my future projects.