locked
Is it possible to create a change-tracked pure poco? RRS feed

  • Question

  • Hi,

     

    EF 4.0 offers some great new concepts:

    - we can now create entity objects as poco's (i will call these EF poco's from here on)
        -> decouples our business layer from the Entity Framework dependency
    - with Self-Tracking-Entities, we can now do client-side change tracking
        -> helps out A lot in N-tier scenarios

     

    Question:
    I now want to decouple my business entities from my WCF Service contract.
    So I do not want to expose Business Objects to the outside world.

    In the upcoming part, i will clearly distinguish between 2 kinds of pocos:
    1. My Business Objects = database mapped entities = EF Pocos
    2. Pure Pocos = my service contract

    Is it possible to create Pure Poco's and use the client-side change-tracking features that were introduced for Self-Tracking-Entities?
    So that my Pure Poco's are change-tracked, and in my WCF-service, I can decide how to handle these changes, for instance:
    - mapping these Pure Poco changes back to my Business Objects (EF pocos)
    - or calling another service that will handle the changes

     

    Thanks,
    Koen

    • Moved by Jonathan Aneja -- MSFT Monday, May 10, 2010 9:56 PM (From:ADO.NET Entity Framework and LINQ to Entities (Pre-Release))
    Friday, May 7, 2010 2:43 PM

Answers

  • You can only perform change tracking on the client when you control code on both sides of the wire.  Whether your change-tracking code lives in the business object itself in a shared assembly (like EF4 STEs), or you register the service proxies with some external manager on the client to watch for changes is an implementation detail.

    If you prefer the latter route, you can build into your POCO/service objects extra messaging fields to capture data that you can interpret as change notifications within your service layer (such as fields for capturing the original values of the entity upon update).  The client-side "change manager" then is responsible for hydrating these fields before serialization and transmission back to the server.  This creates a lot of extra code overhead though, as you have to build classes to manage change tracking on the client as well as change interpretation on the server.  If you are going down this route, why not just use the STEs you get out of the box that already handle all of this?

    If you are determined on going the POCO route, then your best option is to forget about change-tracking on the client altogether.  Store a snapshot of your outbound entity on the server, then compare values upon receipt of that entity back from the caller.  Expire the snapshot of the original values or serialize to a persistent data store after some reasonable amount of time to control your memory footprint.

     

    Friday, May 7, 2010 4:16 PM