Venturing into ASP.NET MVC

Photo: visualpanic

The first time I sat down to do development on an ASP.NET project, it was clear that it was designed primarily for people who came to it from Windows Forms programming/Visual Basic kind of environment. That was decidedly not my background. Most of my web experience had been in PHP, Perl and Java. On the .NET side, I actually did quite a bit of work on systems-level stuff in C# before ever touching ASP.NET: data migration and munging, Windows services, Web Services, data access layers for reporting services, lots of console apps that did specific back-end stuff, etc.

As a result, the way that viewstate and postbacks work together never felt "natural" to me. I "grew up" with the web being stateless and developed patterns for building applications in that environment. When you suddenly get ASP.NET masking that stateless nature, many of those techniques have to be completely changed.

I have learned to work within that structure, but always wanted something in the ASP.NET ecosystem that was more "webby". I got interested when MonoRail showed up, but for whatever reason, it didn't stick.

Then, earlier this year, I heard about Microsoft's own (horribly clunkily named) project: ASP.NET MVC. After one of the presentations I saw online about it mentioned that it was ASP.NET without viewstate and postback, I was intrigued. That it also implemented (or approximated, depending on your level of pattern religiosity) the MVC pattern closed the deal and I gave it a shot.

The basic idea of MVC and MVC-like approaches to building applications (please save any pedantic discussions of strict compliance for elsewhere) is something I've come to think of as similar to getting food in front of you as a meal. Whether you are talking about a restaurant, your home kitchen or your dorm room, there are 3 basic pieces that map to MVC.

• A supply of ingredients.
• The cooking process in a kitchen
• The presentation of the food on a plate.

Ingredient Supply

In commercial/restaurant kitchens this is a wholesale food vendor, for individuals, it can be a grocery store, garden, farmers' market, etc. Regardless, they're the building blocks for your meal and how you get those ingredients into your kitchen (whatever form it may take).

Some of the ingredients are really raw (whole vegetables), while others area fairly processed already, like worcestershire sauce or pre-breaded chicken cutlets. Regardless, they are rarely in a form that you'd eat them 100% unaltered or uncombined.

Cooking Process

While the definition of cooking can vary greatly, whether you're just nuking a burrito or spending 16 hours smoking a beef brisket, the ingredients are combined and manipulated to get them into a form that you'd actually want to eat.

Eventually, you've got food that's cooked and edible, but either in a pan or sitting on that revolving plate in the microwave: not exactly ready to sit down at a white cloth table or in front of the TV to watch Doctor Who.

Plating

The now-cooked food is arranged on a plate for presentation to a diner. Sometimes, a quick drizzle of sauce or a sprig of parsley is added and the food is sometimes manipulated a bit, but only for presentation purposes.

On the Web

If you think in terms of that meal preparation for MVC, your data/model becomes the ingredients, your controller manipulates the data and gets it ready for output to the browser as HTML.

When thought of this way, it's clear that the meal and to whom it's being presented can vary how much is going on at each level. For instance, when cooking for myself, I often just dump the food onto a paper plate, even if I use some really good ingredients. Similarly, some meals for guests start with very simple ingredients, but involve a great deal of manipulation and involve elaborate presentation. It all depends.

My First Project

In order to explore this framework and some other stuff I wanted to try out, I started building a small app that I've been wanting. Unhappy with my invoicing options, I threw together the skeleton of an invoicing app using ASP.NET MVC. Needing a name for project files, namespaces, classe, databases, etc., I called it Uome (You Owe Me).

I've now built enough of it to understand what I did wrong and think I have a better footing for doing more serious apps. It's servicable, though not something I'm itching to share (until I re-do it). However, it made it abundantly clear that, for several personal projects I've got in the hopper, this is going to be my framework of choice.

I actually also chose this project to stretch my legs a bit with Subsonic, another tool I've been watching for the last few months and have to say that the combination is quite enjoyable to build things with.

Things on the ASP.NET MVC front aren't stable at the moment. The current release is "Preview 3" and each of the preview releases has required rewriting bits of apps built on the previous layer. As such, if you've got some personal or internal project (like Jeff Atwood is doing with his stackoverflow.com), it's fun stuff to mess with. By the time it hits its full release, I should be fairly comfortable with it and will be looking to apply it to clients' projects.

And, given the modularity for things like using different view engines, other languages like Ruby, etc. it's something that, if you do any ASP.NET development, you should at least look into and keep an eye on.

There's lots of good content in screencast form that offers a good overview and a decent portal full of content for digging deeper into the topic if you're interested.