Question

I have a complex model class, of which only a few string columns should be (and can be) edited. When I open and edit a couple of these columns and save the form, the string columns are posted back just fine, but the other (array) columns are null — this breaks the save to Entity Framework.

What’s the proper way to go about this with MVC3 and EF?

Answer 1

I think this is a common problem. There are a couple of approaches I use:

1) This is my recommended approach. Use a viewmodel which encompasses only the properties that you want to be edited. This can then be bound back directly as you are currently trying to do. The problem with this approach is that you then need to copy the properties from and to your EF objects. If the naming is consistent you may be able to use a dumb reflection copier. If they are not, or you need to walk a graph to copy them back, then I tend to end up putting that custom logic into the viewmodel class. (Which makes it more than a pure view model – but nothing other than the viewmodel and the view needs to be aware of its existence.)

2) Use modified binding. You can specify [Bind(Exclude=”this,that,theother”)] to stop certain properties being nulled out, and when the properties are scalar properties that you simply don’t want to have on screen, use Html.HiddenFor(x=>x.myprop)

Another approach is

3) Custom Binders. You can register your own custom binder and engineer whatever you need. This isn’t an approach I’ve used. but might work well.

The reason 1) is a much better approach than 2) (IMHO) is that 2) exposes your entire model for update via HTML POST. The MVC binder will bind changes to anything that fits, so a well crafted POST can do some unexpected things: traversing relationships you hadn’t intended to expose and updating properties. The Viewmodel pattern on the other hand needs to have entities that only expose the fields the user interacts with so are safe to bind to.