Hello all.
I work with a senior developer who is a guru .NET architect. We have had many constructive arguments over the last 6+ months and generally I concede defeat in most of our discussions. I have learned stacks from working with him. There is one design problem we are currently in disagreement with, however, and I would like some opinions/suggestions because he hasn't managed to convince me of his position, and I will stick to my guns until someone can give me evidence that I am wrong.
We use Entity Framework 4.0 and we use BOTH persistance aware AND Self Tracked Entities in different models. We started using Self Tracked Entities for tracking changes to Entity Graphs that we serialised/deserialised over the WCF wire to our Silverlight application. It works fantastically. We have also started using Self Tracked Entities for models that we are NOT taking across WCF, but many remain as persitance aware Entities/Models.
My co-worker believes that Entity Frameworks ObjectContext should be kept around for the shortest time possible. He insists that it should only be around for the length of time needed to do a query and the length of time needed to persist something. Any business work done with Entities should be done detached. For each Entity Model we have, we have a query class and a persistance class that are both IDisposable and have the ObjectContext at instance scope and have the query/persistance logic in methods. We use these query/persistance classes in our business logic rather than using the the ObjectContext directly in business logic. When these class instances are constructed so is the ObjectContext and when Disposed, so is the ObjectContext Disposed. These classes are like wrappers around our LINQ operations seperating EF from the business logic and assisting with LINQ query re-use.
Now first consider non-Self Tracked Entities:
I understand why he wants this and the desire to not have a long running ObjectContext, but my problem is that he always wants even trivial business logic to be detached from the ObjectContext and the fact that we have a seperate query and persistance context under our design means that there is no ObjectContext state tracking of Entities being used in our business logic. For non-Self Tracked Entities this means that if we modify Entities in our business logic we must also set the Modified state of the entities manually prior to persisting. This is a REAL pain when persisting complex graphs with multiple changes. Also I doubt we can do it manually as well as EF does it automatically.
For our Self Tracked Entities this situation is the same because tracking is only turned on when graphs are de-serialised and so when working WITHIN a service where the query was performed, detached from the Context, there is still no tracking with Self-Tracked Entities.
My question is, what is the best practice for Entity Framework use and how should an Entity Framework DAL be designed? How long should the ObjectContext be around? Should business logic always be done detached from the ObjectContext? If so how do we do state tracking when working detached from the ObjectContext? One option I am thinking about is converting ALL of our entities to Self-Tracked Entities and using some graph traveral code to traverse queried graphs and turn tracking on for all of the Entities in the graph so Self Tracking is turned on even when working service side (basically mimicing what happens when the Self-Tracked Entities graph is de-serialised)...
I am not proposing that we keep the ObjectContext around for long periods of time, but working detached between query and persistance and losing the benefits of the ObjectContext state tracking to me seems silly...we are losing one of the great benefits of EntityFramework...
Sorry for long post...any help appreciated.