Home/ Questions/Q 4553860
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T17:00:26+00:00

I am using the Service Layer –> Repository –> Entity Framework (Code-First) w/POCO objects

  • 0

I am using the Service Layer --> Repository --> Entity Framework (Code-First) w/POCO objects approach, and I am having a hard time with updating entities.

I am using AutoMapper to map my Domain Objects to my View Models and that works good for getting the data, no how do I get that changes back into the database?

Using pure POCO objects, I would assume that there is no sort of change tracking, so I see my only option is to handle it myself. Do you just make sure that your View Models have the EXACT same properties as your Domain Objects? What if I just change a field or two on the View Model? Won’t the rest of the fields on the Domain Object get overwritten in the database with default values?

With that said, what is the best approach?

Thanks!

Edit

So what I am stumbling on is this, lets take for example a simple Customer:

1) The Controller has a service, CustomerService, that calls the services GetCustmoerByID method.

2) The Service calls into the CustomerRepository and retrieves the Customer object.

3) Controller uses AutoMapper to map the Customer to the ViewModel.

4) Controller hands the model to the View. Everything is great!

Now in the view you do some modifications of the customer and post it back to the controller to persist the changes to the database.

I would assume at this point the object is detached. So should the model have the EXACT same properties as the Customer object? And do you have to make hidden fields for each item that you do not want to show, so they can persist back?

How do you handle saving the object back to the database? What happens if your view/model only deals with a couple of the fields on the object?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You are absolutely right that with a detached object you are responsible for informing the context about changes in your detached entity.

    The basic approach is just set the entity as modified. This works for scalar and complex properties but it doesn’t work for navigation properties (except FK relations) – for further reading about problems with navigation properties check this answer (it is related to EFv4 and ObjectContext API but same problems are with DbContext API). The disadvantage of this approach is that all fields in DB will be modified. If you just want to modify single field you still have to correctly fill others or your database record will be corrupted.

    There is a way to explicitly define which fields have changed. You will set the modified state per property instead of whole entity. It is little bit harder to solve this on generic approach but I tried to show some way for EFv4 and for EFv4.1.

    • 0