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.
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.
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.
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:
- This makes it quicker to understand where to put some of the code that does the key work of the application.
- 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.