How can I keep my MVC Views, models, and model binders as clean as possible?

Posted by MBonig on Stack Overflow See other posts from Stack Overflow or by MBonig
Published on 2010-03-08T20:31:05Z Indexed on 2010/03/08 20:36 UTC
Read the original article Hit count: 222

Filed under:

I'm rather new to MVC and as I'm getting into the whole framework more and more I'm finding the modelbinders are becoming tough to maintain.

Let me explain...

I am writing a basic CRUD-over-database app. My domain models are going to be very rich. In an attempt to keep my controllers as thin as possible I've set it up so that on Create/Edit commands the parameter for the action is a richly populated instance of my domain model. To do this I've implemented a custom model binder.

As a result, though, this custom model binder is very specific to the view and the model. I've decided to just override the DefaultModelBinder that ships with MVC 2. In the case where the field being bound to my model is just a textbox (or something as simple), I just delegate to the base method. However, when I'm working with a dropdown or something more complex (the UI dictates that date and time are separate data entry fields but for the model it is one Property), I have to perform some checks and some manual data munging.

The end result of this is that I have some pretty tight ties between the View and Binder. I'm architecturally fine with this but from a code maintenance standpoint, it's a nightmare.

For example, my model I'm binding here is of type Log (this is the object I will get as a parameter on my Action). The "ServiceStateTime" is a property on Log. The form values of "log.ServiceStartDate" and "log.ServiceStartTime" are totally arbitrary and come from two textboxes on the form (Html.TextBox("log.ServiceStartTime",...))

protected override object GetPropertyValue(ControllerContext controllerContext,
                                               ModelBindingContext bindingContext,
                                               PropertyDescriptor propertyDescriptor,
                                               IModelBinder propertyBinder)
{
        if (propertyDescriptor.Name == "ServiceStartTime")
        {
            string date = bindingContext.ValueProvider.GetValue("log.ServiceStartDate").ConvertTo(typeof (string)) as string;
            string time =
                bindingContext.ValueProvider.GetValue("log.ServiceStartTime").ConvertTo(typeof (string)) as string;
            DateTime dateTime = DateTime.Parse(date + " " + time);
            return dateTime;
        }
        if (propertyDescriptor.Name == "ServiceEndTime")
        {
            string date = bindingContext.ValueProvider.GetValue("log.ServiceEndDate").ConvertTo(typeof(string)) as string;
            string time =
                bindingContext.ValueProvider.GetValue("log.ServiceEndTime").ConvertTo(typeof(string)) as string;
            DateTime dateTime = DateTime.Parse(date + " " + time);
            return dateTime;
        }

The Log.ServiceEndTime is a similar field.

This doesn't feel very DRY to me. First, if I refactor the ServiceStartTime or ServiceEndTime into different field names, the text strings may get missed (although my refactoring tool of choice, R#, is pretty good at this sort of thing, it wouldn't cause a build-time failure and would only get caught by manual testing). Second, if I decided to arbitrarily change the descriptors "log.ServiceStartDate" and "log.ServiceStartTime", I would run into the same problem. To me, runtime silent errors are the worst kind of error out there.

So, I see a couple of options to help here and would love to get some input from people who have come across some of these issues:

  • Refactor any text strings in common between the view and model binders out into const strings attached to the ViewModel object I pass from controller to the aspx/ascx view. This pollutes the ViewModel object, though.
  • Provide unit tests around all of the interactions. I'm a big proponent of unit tests and haven't started fleshing this option out but I've got a gut feeling that it won't save me from foot-shootings.

If it matters, the Log and other entities in the system are persisted to the database using Fluent NHibernate. I really want to keep my controllers as thin as possible.

So, any suggestions here are greatly welcomed!

Thanks

© Stack Overflow or respective owner

Related posts about asp.net-mvc