What is the purpose of self tracking entities?

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.

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.

– Calanus Feb 23 at 16:08 @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. – Ladislav Mrnka Feb 23 at 16:47 So, to summarise, STEs are really a form of Data Transfer Object that has change tracking abilities? – Calanus Feb 24 at 13:06 @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. – Ladislav Mrnka Feb 24 at 13:11.

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.

blogs.msdn.com/b/efdesign/archive/2009/0....

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 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.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.