What is the purpose of self tracking entities?

Question

I've been reading about self-tracking entities in .net and how they can be generated from a *.edmx file. The thing that I'm struggling to understand is what generating these entities gives you over the basic EF entities? Also, some people have mentioned self tracking entities and Silverlight, but why would you use these rather than the client side or shared classes generated by RIA services?

What is the point of self-tracking entities and why would you use them?

Kahaleel

Answer 1

Self tracking entities (STE) are implementation of change set (previous .NET implementation of change set is DataSet). The difference between STE and other entity types (POCO, EntityObject) is that common entity types can track changes only when connected to living ObjectContext. Once common entity is detached it loose any change tracking ability. This is exactly what STE solves. STE is able to track changes even if you detach it from ObjectContext.

The common usage of STE is in disconnected scenarios like .NET to .NET communication over web services. First request to web service will create and return STE (entity is detached when serialized and ObjectContext lives only to serve single call). Client will make changes in STE and pass it back in another web service call. Service will be able to process changes because it will have STE internal change tracking available.

Handling this scenario without change tracking is possible but it is much more complex especially when you work with whole object graph instead of single entity - you must manually merge changes received from client to current state in database.

Be aware that STEs are not for interoperable solutions because their functionality is based on sharing STE code between server and client.

Aircraft

OK - so with regards to RIA services which provides data to silverlight clients, when would there be a need to use RIA and STE together? – Kahaleel

@Calanus: Perhaps this will answer your question: forums.silverlight.net/forums/p/157143/351463.aspx Otherwise you should ask separate question about it with all realted tags because WCF RIA services are very specific topic. I have never used RIA services. – Aircraft

So, to summarise, STEs are really a form of Data Transfer Object that has change tracking abilities? – Kahaleel

@Calanus: No. STEs are not data transfer object. Data transfer objects are only for passing object from one tier to other tier but STEs are entities which are directly persisted to DB by EF. – Aircraft

Answer 2

The main purpose is to aid in N-tier development. Since they're self-tracking, you can serialize them over, say, a WCF service, then de-serialize them back, and they will still know which changes have been made, and are pending for the database.

Self-tracking entities know how to do their own change tracking regardless of which tier those changes are made on. As an architecture, self-tracking entities falls between DTOs and DataSets and includes some of the benefits of each.

http://blogs.msdn.com/b/efdesign/archive/2009/03/24/self-tracking-entities-in-the-entity-framework.aspx

Towel