MVC Bootcamp takeaway

I just finished three days of Headspring MVC bootcamp training with Jimmy Bogard.

Impressions:

Great training, I would highly recommend anything these guys offer. I enjoy a fast pace, hands on (lots of programming exercises) style of training, and that's what I got. Jimmy is a good teacher... I already knew that, since I've been reading his blog for the past year or so and I've picked up a lot a good pointers to things that help me in my work. He is also a good communicator teaching in front of a room full of diverse programmers. If you are new to MVC like I am, this course is great for introducing concepts that may be new to web forms programmers... but like the MVC book that Jimmy co-authored, the class goes way beyond the introduction by showing how they leverage some of the features in MVC (ActionFilters and ResultFilters, HtmlTemplates, Model binding and validation...) to build applications quickly that are easier to maintain. We used the release candidate of ASP.Net MVC 2 in class.

Takeaway:

We use ASP.Net web forms at work, and I don't think we will change to MVC in the near future. Maybe at some point in the next year - I'm not sure yet. I knew that going into this class, but I also hoped I would learn about valuable patterns and tools that we can use right now (yes, even in web form development) that will make us go faster or that will make our apps easier to maintain. My hopes were not dashed... here is my list of "valuables" (this list is more for me and my team... but if someone else gets something out of it, great!):

1. Model Binding - this seemed magic to me at first, and comes for free in the MVC framework. When a form posts to the server, the action method ("event handler" for us web form devs) that accepts the post takes the payload in as a parameter... which is already mapped to a model class. No tedious "model.FirstName = txtFirstName.Text" code to write. This would be nice to have in our work... there may already be something similar in web form development that I just don't know about. If not, I don't think it would be much work to write some convention-based code that does this type of work for us.
2. ViewModel validation using property attributes - we write a lot of repetitive code that validates email addresses, phone numbers, department numbers, etc. It would be nice to be able to put an attribute on a property in our ViewModel class (for example, "[EmailAddress]" and have the form post automatically check these for us.
3. Html builders - the RC version of ASP.Net MVC 2 has helper methods like "Html.EditorFor(x => x.FirstName)" which spit out the label, text box, and validation message element for a property called "FirstName" on a view model. We do something similar with user controls for our pages... but we could do a lot better, and the implementation in MVC gives me some ideas. MVC 2 even has an "Html.EditorForModel()" method that will render the entire collection of form controls needed for a particular view model. Handy!
4. Use an IoC container like StructureMap - we have been using poor man's dependency injection for a few months now, but we need to step it up and use the factory pattern to do the heavy lifting for us... if a presenter/controller class needs an IPersonRepository, get it from the factory. Stop explicitly injecting it when the controller is requested.
5. Use AutoMapper to map domain models to view models. Jimmy is right, mapping code is tedious to write.
6. Move to NHibernate. I've been gently moving our team away from classic data access layers with ADO.Net for the past year. We use a really simple, in-house ORM that I wrote (yes, I know... I re-invented the wheel - but it seemed the best way to transition) that reduces the number of stored procedures per project by ~90%. It is time to go all the way, so we can realize the performance, maintainability, and code-quality benefits NHibernate will bring.
7. Lighten up our presenter/controller classes. These are still pretty heavy in our team... something Jimmy showed us, and I will be looking up in CodeCampServer, was using the Strategy pattern to execute commands when a form requests something. For example, a form posts to the server and needs to save data... CodeCampServer uses an "ExecuteCommand" method to pass the ViewModel payload, and the domain entity type, to another class that handles the work of mapping and persisting.

I'm sure I am forgetting something... I took good notes though that I'm sure will be printed and worn out over the next months. Thanks for a great class Jimmy!