Entity Framework Feature Suggestions

Better support for Self-Tracking Entities

The current implementation of self-tracking entities is error-prone especially when combined with disconnected scenarios, such as, when using WCF services. The reconciliation process with the ObjectStateManager is convoluted and makes it easy to trip up when saving larger aggregates with Self-Tracking Entities. I would like to see more effort put in to improve the Self-Tracking Entities template and to improve how EF and Self-Tracking Entities interact.

372 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    MarkMark shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    7 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • PaulPaul commented  ·   ·  Flag as inappropriate

        I would like to see a different approach here that also works with the Code First POCO way of working in a detached/WCF environment. We have lots of problems in this area when we send an edited or new entity to a service to be saved. We have mix of entities in the object graph, some of which exist in the database and some that are new. We then have to iterate the object graph setting the entity state, this is complex.

        I would like to see you offer a solution whereby you can specify a property on your POCO class that contains entity state data. You specify this property through the fluent API. When EF then deals with the entity it reads the entity state from this property.

        So to take a very simple example, let’s say that we have a Customer entity. We would therefore add a property to the class named something like EntityState of type int (its values should correspond to the EntityState enum but for reasons of not having to have a dependency to this enum it shouldn’t be of that type, just an int). We would also add code to our POCO class to update this value when the state of the entity changes (on the client). As this is a POCO class it would be up to the developer to write this code.

        You would then map to this property using the fluent API (it would need some way of allowing you to specify that this property holds entity state data).

      • Ladislav MrnkaLadislav Mrnka commented  ·   ·  Flag as inappropriate

        STEs are T4 template and you can just take template and code any changes or improvements you require yourselves!

        STEs are wrong concept from the beginning because they cover very small area of problems and they work only with .NET client. It would be better if ADO.NET team takes their effort to more important issues and feature requests.

      • YaakovYaakov commented  ·   ·  Flag as inappropriate

        Yes please - working on a project where this is causing all sorts of problems

      • bigyesbigyes commented  ·   ·  Flag as inappropriate

        Yes, please imporve Self-Tracking Entities :
        - add HasChanges property
        - detect returns to orginal state (after multiple updates)
        - add RejectChanges (local)
        - add the concept of context on the client side to avoid duplicates (mutiple .NET entites references for same row in DB) due to multiple WCF call to the service. (this concept exists in DATAServices + RIA Services)
        - work in concert with DATAServices and RIA Services teams to avoid multiple solutions for the same need : validate and update data in a disconnected sceanrio

      • teydeteyde commented  ·   ·  Flag as inappropriate

        STE doesn't work at all when we try to unit test our creation. It's not unusual to unit test wcf services by calling the assembly directly. What happens next, is that the unit tested entity is saved in a different data context from where it were received, and all goes kaboom. The acrobatics we have to do with the tracker and the data context, and still not getting it working properly, is nothing but preposterous.

      Feedback and Knowledge Base