Question

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

Answer 1

You can use ViewModel:

class ViewModelClass 
{
    [DateValidationAttribute]
    public property DateTime ServiceStartTimeDate { get; set; }
    [TimeValidationAttribute]
    public property DateTime ServiceStartTimeTime { get; set; }
}

DefaultModelBinder binder doesn’t need any modification to bind these fields. Then you can write function to combine these fields:

class DateUtil
{
     public static DateTime CombineDateAndTime(DateTime Date, DateTime Time);
}

Then you get entity from database:

var entity = context.GetUpdatedEntity(id);
entity.ServiceStartTime = DateUtil.CombineDateAndTime(viewModel.ServiceStartTimeDate,viewModel.ServiceStartTimeTime);

If you really want to have it in model binder, you can do it like this:

public class DateAndTimeModelBinder : DefaultModelBinder
{
    protected override object GetPropertyValue(ControllerContext controllerContext,
                                           ModelBindingContext bindingContext,
                                           PropertyDescriptor propertyDescriptor,
                                           IModelBinder propertyBinder)
    {
        if (propertyDescriptor.PropertyType == typeof(DateTime))
        {
            string time = bindingContext.ValueProvider.GetValue(CreateSubPropertyName(bindingContext.ModelName, propertyDescriptor.Name + "Time")).ConvertTo(typeof(string)) as string;
            var date = base.GetPropertyValue(controllerContext, bindingContext, propertyDescriptor, propertyBinder);
            if ((date != null) && (time != null))
                return CombineDateAndTime(date, time);
        }
        return base.GetPropertyValue(controllerContext, bindingContext, propertyDescriptor, propertyBinder);
    }
}

When DateTime field is being bound, binder looks if there is additional form field with “Time” at the end (if we bind “ServiceStartTime”, it look for “ServiceStartTimeTime”, so you bind date portion to “ServiceStartTime” field and time portion to “”ServiceStartTimeTime”). If there is, it adds its value to date. You write it once and will work for every field. Code above will surely not work, it needs some adjustments, but shows idea.