EF4 POCO: Snapshot vs Self-tracking over WCF

Question

Last year I developed a data access service for our project using Entity Framework (.NET3.5 of course) and using Julie Lerhman's book as a guide developed state tracking POCO objects. We use WCF and also have Silverlight 3 clients. We are moving to .NET 4.0 and I want to switch to using code generation to eliminate wasted developer time writing the POCO classes and the translation classes.

With the research I have done there seems to be 3 ways of state tracking POCOs:

1) Changed tracked proxies: Doesn't seem to be useful for us as it seems this doesn't work over WCF serialisation.

2) Snapshot based: Snapshot is taken when POCO entity graph is retrieved, returned graph from client is compared with that snapshot and differences are compared...seems good to me.

3) Self-Tracking Entities: Code generator generates logic for doing self tracking within the POCO objects. This seems close to what we do now except it is all generated for us.

I am trying to work out what the advantages and disadvantages are between all of these methods. I am guessing that 1 and 2 are "connected" and that they need the ObjectContext that the POCOs were originally queried from to remain instanciated, but haven't been able to confirm this. I also don't see a reason why anyone would really bother with option 1 given that option 3 seems to do the same and more...

Snapshot seems the simplest to me, but if this requires an ObjectContext to remain open for a long time I am not so sure...

I am only a junior programmer so any advice here, especially with regards to Silverlight 3 (I believe options 2 and 3 work with Silverlight 3 but 2 may have issues) is much appreciated.

Atomicity

As an update, I am now using State Tracked Entities in our WCF/Silverlight 4 application and they work pretty well (though having issues with deletes). Navigation Properties are TrackableCollections now which derive from ObservableCollection so binding to XAML in a dream. I reccomend this solution very much. – Atomicity

Possible duplicate of #3815206 and of #6116502 – Hamlett

Answer 1

Go with Option 3. Self-Tracking Entities as this is what they were designed for.

"Self-tracking entities are optimized for serialization scenarios"

This post gives a good demonstration.

Sinistrad

Self-Tracking-Entities (STE) has one major drawback. You must share the code generated by the T4 Code-generator for the STE to work properly. This means that you cannot use the data service reference Metadata generated classes on the client side, thus a limitation to .NET client side only. – Takeshi

Yes you are right about not being able to generate client proxies. We coded our proxies by hand and shared the code on the client. Technically you can just share the binaries containing the entities with your .NET or Silverlight client (you have to build a .dll compatible with Silverlight if your client is Silverlight). – Atomicity

Not anymore. STE are not recommended anymore. – Utta

I agree with the objections to Self Tracked Entities, but MS is yet to provide a true alternative where object graphs can be tracked in a disconnected manner. What is needed is a solution that allows graphs to be manipulated when disconnected and re-synced on the server side. Removing the tracking logic from the POCOs is fine, provided the DbContext ha some functionality for walking whole object graphs and deciding what need to be updated. Right now there is no such functionality. There is no equivalent to STE in the DbContext world. – Atomicity

Answer 2

The other two options are only applicable when changes are done when the objectcontext is around. Your only option is STE. With STE, entities would keep track of their own changes. When the modified object graph is sent to the server, you can just play those changes as shown below. db.Dustomers.ApplyChanges(customer); db.SaveChnages();

With STE, you can create your entiites in a class library project and share them between a WCF client, silverlight client, asp.net and wpf. So this gives you reuse of entities for various clients.

Rootlet