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.
Whitney Kew commented
We would like an ADO.NET Self-Tracking Entity Generator with DbContext support.
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 Mrnka commented
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.
Yes please - working on a project where this is causing all sorts of problems
Just adding my twopennyworth as well.
See http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/fb40daee-215c-46bf-96c2-ec639141c768 for a good exploration of the issues surrounding using STEs in conjunction with WCF.
- incorporate a way to "clean" the object graph on the client side so you only have the entities attached that you're interested in.
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
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.