开发者

EntityFramework, Unit of Work - Tracking changes of custom data and sending it via WebService

开发者 https://www.devze.com 2023-03-18 08:00 出处:网络
We have Unit of Work implemented in EntityFramework, so when we use ObjectContext and make any changes to the Entity it is tracked and then on SaveChanges it is all reflected in underlying database.

We have Unit of Work implemented in EntityFramework, so when we use ObjectContext and make any changes to the Entity it is tracked and then on SaveChanges it is all reflected in underlying database.

But what if I want to track changes for my custom class, so every modifications are tracked down and sent through webservice call ?

I have webservice which provides me some data, that data is displayed in datagrid and then may be modified. I want to track all the changes down and then be able to send back through webservice the data only that have been modified. Is there any solution for that like EntityFramework or POCO or whatever ? Or I have to implement my开发者_StackOverflow own Unit of Work pattern for it ?


Change tracking works only when entity is attached to the context. There is special type of entities called Self tracking entities which is able to track changes on the client side when exposed with web service but these classes are still your primary entities (not custom objects) and they apply their tracked state directly to the context.

What you describe has nothing to do with unit-of-work pattern. You are looking for change set pattern which is able to pass only differences back to the service. Implementation of such classes is completely up to you. .NET doesn't provide them. .NET offers two implementations of change set pattern

  • mentioned Self tracking entities for EF
  • DataSet and related classes

Both these implementations transfer by default all data (moreover at least DataSets have by default both old and new state in the message). Both data sets and STEs share same limitations - they are very badly interoperable.


Change tracking at the property level should not be left to the client of a WCF call, for a variety of reasons. If you use a DTO (Data-Transfer Object) pattern, you should be able to keep your individual objects small enough to avoid having any significant overhead from sending the entire changed object across the wire. Then, on the server side, you load the current version of the object out of your database, set the values provided by the DTO, and let Entity Framework track the changed properties.

public SavePerson(Person person)
{
    using(var context = _contextFactory.Get())
    {
        var persistentPerson = context.People.Single(p => p.PersonId == person.PersonId);
        persistendPerson.FirstName = person.FirstName;
        /// etc. (This could be done with a tool like AutoMapper)
        context.SaveChanges();
    }
}

If you're changing multiple objects on the client side, and you want to keep track of which ones the user has changed, you could have the client be responsible for keeping track of the objects that get changed and send only those objects to the web service in bulk. There, you can apply the same pattern and wait to SaveChanges until all of the objects have been updated.

Hopefully this helps.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号