Thanks Again StackOverflow!

About a month ago, I wrote a brief post about starting a new job.  In it, I tipped my hat to StackOverflow Careers, for connecting me with my new employer.  Yesterday, I received a package from FedEx.  I was puzzled, since I didn’t recall ordering anything recently.  But upon opening it, I discovered a nice StackOverflow-branded portfolio, pen and card with The Joel Test on it.  In the pocket was a version of my profile printed on high-quality paper.

I appreciate the gesture, and thank StackOverflow Careers and the StackExchange team not only for the portfolio (which I’ve already replaced my previous portfolio with), or for creating a great site for connecting developers with employers that value developers, but for the whole collection of Q & A sites that make software development (and many other fields of endeavor) easier to learn.

 

 

From Web Forms to MVC

In the weeks since my last post, I’ve been thrown into the deep end of the pool learning ASP.NET MVC 3 and a number of other associated technologies for a healthcare information management application currently scheduled to deploy this July.  Having developed web applications using webforms since 2003, I’ve found it to be a pretty significant mental shift in a number of ways.

No Controls

There are none of the controls I’ve become accustomed to using over the years.  So in addition to learning the ins-and-outs of MVC 3, I’ve been learning some jQuery as well.

No ViewState

Because there’s no viewstate in MVC, any information you need in more than one view should be available either in the url’s query string, the viewmodel, or be retrievable via some mechanism in your view’s controller.  In the application I’m working on, we use Agatha.

More “Pages”

Each CRUD operation gets its own view (and its own viewmodel, depending on the circumstance).  This actively encourages separation of concerns in a way that webforms definitely does not.

A Controller is a Lot Like Code-Behind

I’ve been reading Dino Esposito’s book on MVC 3, and he suggests thinking of controllers this way fairly early in the book.  I’ve found that advice helpful in a couple of ways:

  1. This makes it quicker to understand where to put some of the code that does the key work of the application.
  2. It’s a warning that you can put far too much logic in your controllers the same way it was possible to put far too much into your code-behind.

Using Agatha has helped to keep the controllers I’ve written so far from being too heavy.

More to Come

This barely scratches the surface of my experience with MVC so far.  None of the views I’ve implemented has been been complex enough yet to benefit from the use of Knockout JS, but future assignments will almost certainly change this.  We’re also using AutoMapper to ease data transfer between our domain objects and DTOs.  In addition to using StructureMap for dependency injection, we’re using PostSharp to deal with some cross-cutting concerns.  Finally, we’re using RavenDB for persistence, so doing things the object database way instead of using SQL Server has required some fundamental changes as well.