views:

2318

answers:

2

Hello

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.

+7  A: 

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.

willbt
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.
Tri Q
+1  A: 

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.

zeeshanhirani