3

I'm working on an MVC3 project where I noticed that certain fields in the database are being set to null when that record is updated from the UI. This happens because those fields are not present on the form on post. I know this can be solved by adding HiddenFor entries for these, but that wouldn't be a great approach since any new fields would need to be added there as well. I'm hoping to figure out a better solution.

A little elaboration on how the project is structured:

We have DTOs that match the EF entities exactly to simplify mapping. So the DTOs have every field present in the entities & database. We use the DTOs as our models.

The controllers pass the DTOs to a service layer. The service layer maps the DTO to its respective entity (using AutoMapper), and passes it to the persistence layer. The persistence layer is what actually uses the DbContext to save changes.

Say we have a Client DTO with a Name member and a FolderPath member, and a view that only has the Name member on its form. The form posts, and that FolderPath is null. That null value persists all the way to the update in the persistence layer. Somewhere along the line I have to specify that I don't want that particular value overwriting what's in the database.

From what I've gathered researching this on SO for about an hour, one approach might be...

  1. Keep the DTOs minimal in scope, for a specific set of fields that we know we will have on a form in a view.
  2. Tell AutoMapper to ignore anything that exists in the destination but not the source per this answer.
  3. In the service layer, when mapping the DTO to the entity, first retrieve the existing entity from the database. The mapping will only overwrite the members that are part of the DTO, and any other values will persist since they're being retrieved from the database.

Would this be a valid approach? Are there any better or more common ways to address this problem?

Community
  • 1
  • 1
John Straka
  • 1,874
  • 5
  • 28
  • 49

1 Answers1

2

I would go with Option 1 and have view / html form specific models. It's the cleanest solution, IMHO.

There's also the major issue that the other ways leave you open to hacking... i.e. if I knew other fields / properties on your model, I could craft a form post with that information and get it saved.

Charlino
  • 15,802
  • 3
  • 58
  • 74
  • I meant the numbers as steps to one solution rather than distinct choices, as I think they would be necessary for all of the members in the entity but not the DTO to persist. Also, this is an intranet-only application for a small number of people, so hacking concerns are not too high of a priority. – John Straka Aug 08 '12 at 16:24