ASP.NET MVC - First Impressions

Another item on my Tech ToDo is MVC Frameworks. I have been meaning to get in to MVC frameworks for ASP.NET pretty much since I first heard of them so it has been great to finally get a chance to sit down and have a tinker.

What is MVC?

MVC stands for Model View Controller – it’s a software design pattern that aims to separate the concerns of:

The Presentation of the Data (The View)

How the data needs to be viewed should not impact any other code. Code should take the data and then build its own representation based purely on that. For example, if we had an awesome Philly steak and cheese sandwich, we could present it in a number of ways - we could have a photo, we could have a video of someone chowing down on it, or we could just put how it makes us feel on plane banner.

What changes about the actual sandwich? Nothing. Presentation changes should not require changes in the data.

The Data Itself (The Model)

The model is basically the heart of the data. This is where we represent our problem in code. It includes all of the validation, storage and general guts of the application. Think of the model as the steak and cheese in an awesome sandwich. If you were to take it away from the awesome sandwich, it would just become two mundane slices of bread. Without the bread, the steak and cheese is nothing, without the steak and cheese the bread is nothing. Without the model, the code serves no purpose. The model is an awesome sandwich with awesome filling :)

The One Who Makes It Happen (The Controller)

So we have established that we have an awesome sandwich and several ways to present it. But how do we actually get to the point where we have a view of an actual sandwich?

Enter the controller. Think of the controller as the guy/girl you say “one awesome Philly steak and cheese sub please”, give them your cash. They then run off, take what you have said and make it happen. Without the controller, no sandwich gets made and you never get to see it.

Why Use an MVC Framework?

There are several reasons for using an MVC framework over traditional ASP.NET WebForms development:

• They promote separation of concerns.  Each element of the MVC triad should not rely on the implementation of another. While there is a well-designed interface between the appropriate elements, how the interface is actually implemented should have no effect.
• They increase testability.  Ask any WebForms developer if they test the code-behind for their pages. I guarantee most of them will say “no”. The WebForms model is not test-friendly at all (due to the crippling HttpContext class). Taking ALL of the model away from the view and placing in its own place enables you to poke and prod it to your hearts content.
• Ability to create user-friendly, cleaner URL’s.  MVC frameworks have complete support for URL rewriting which means you can create URL’s like “myweb.com/profiles/rob” rather than “myweb.com/profile.aspx?id=1383067829”.
• Anything else you feel should be here? Comment and let me know!

Requirements to Get Going

I am currently running Windows Vista Home Premium which comes with IIS7 (which is WAYYY better than IIS6!), but that is not required, you will need however:

• Visual Studio 2008 (Costs) or Visual Web Developer 2008 Express (FREE!).
• ASP.NET MVC Framework from the ASP.NET MVC site.

That’s about it :) I do highly recommend the VWD Express Edition, it’s really rich (especially for a free editor) and TBH, there is not a great deal you cannot do in the Express version over the Pro version.

I then started working my way through the MVC Contact Manager sample application (click here and scroll to the bottom – MS please add anchors to headers! Even if you do not link to them!).

My First Thoughts

It’s NOT WebForms!

“Well Duh”

Sure, but I have been doing WebForms development for a couple of years now, so I have gotten pretty used to the pain points of it.. While I have tried to control bad habits (e.g. putting too much business stuff in the page code-behind) – it’s easy to be naughty right? MVC totally turns it all on it’s head, come in to it with an open mind and do not expect to be able to quickly port WebForms code.

Don’t Be Afraid of the Code-In-The-Markup Thing

When I started creating my Views, I got nervous about the amount of code I was placing in the ASPX. In the WebForms & VS2005 world, it was easy to do this and then get errors popping up at runtime. Based on that, I liked to avoid it where possible. You will find yourself putting a lot more code in the ASPX since, well, where else can it go? There is no code-behind :P This said though, Visual Studio 2008 is a hell of a lot smarter than 2005 and I found it picks up most boo-boo’s at compile time.

There’s Helpers Everywhere!

One thing that surprised me with MVC is the amount of static helper classes and extensions methods there are. TBH they are probably needed (especially due to the above point) but this is all stuff adding to the learning curve. Be prepared to learn a whole load of new names!

Get Used to Convention over Configuration

While I admit I have not had a chance to dig deeper into how the MVC elements are all glued together by the runtime, it is immediately obviously after creating your first triad that there is some “convention” being assumed under the hood. For example, here is a typical method in a controller:

   1: public ActionResult Edit(int id)

   2: {

   3:     // Get the Contact with the given ID.

   4:     var contact = 

   5:         (from c in _entities.ContactSet

   6:            where c.ID == id

   7:            select c).FirstOrDefault();

   8:     return View(contact);

   9: }

See the return View(contact) statement? Notice I am not actually telling it what view to return? That’s because MVC automatically runs off and searches the Views\{Controller}\{Action} folder. This is all due to the notion of “convention over configuration”. Rather than expect developers to chunk out lots of code to say where to go, establish a standard and go there instead.

Validation Logic in the Controller

Again, since I am still real fresh to ASP.NET MVC, I am not sure if there is another/better way to do this. During the tutorial it gets you to add some validation logic to the “Edit” action for a contact. Here is the code:

   1: [AcceptVerbs(HttpVerbs.Post)]

   2: public ActionResult Create([Bind(Exclude = "Id")] Contact contactToCreate)

   3: {

   4:     // Validate the Data Passed.

   5:     if (contactToCreate.FirstName.Trim().Length == 0)

   6:         ModelState.AddModelError("FirstName", "First name is required.");

   7:     if (contactToCreate.LastName.Trim().Length == 0)

   8:         ModelState.AddModelError("LastName", "Last name is required.");

   9:  /* snip... */

As you can see, where are performing some validation against the data passed in by the user and then reporting any errors to the ModelState. The ModelState is then available to the view to work with (in a real de-coupled manner, it’s really a dictionary). There are also helper methods in the view like Html.ValidationSummary to display errors reported in the ModelState using a HTML unordered list. Now, I know this is all really useful, but I am not sure how I feel about having the validation of the Model in the Controller.. I would expect the validity of the Model to be verified by the model itself, or surely you are creating some duplication of effort? Would love to hear others thoughts on this? (I am totally willing to accept it is just me being a pain in the ass and I should just accept and love the usefulness of it all!)

In Summation

After a few evenings of tinkering with ASP.NET I can’t help but feel like I am only just looking at the surface, let alone touching it. It looks to be a very powerful and already rich platform (compared to WebForms) which is impressive since it is still very much in it’s infancy.

While it will take some work making my brain work more web-like (i.e. without a PostBack/Event Model) I can feel already it is a much cleaner, smarter way to work. Above all, I am enjoying it. The pattern makes so much sense, allowing me to focus on the task at hand (e.g. coding the model is all about the model).

I’ve yet to really start working with it (e.g. sites from scratch, unaided and test-first) but I don’t think it will be long before I am doing that! Then I look forward to posting hopefully more useful and hands-on posts!

What are your thoughts?