Entity Framework and Application Architecture (loose coupling, etc)

Question

I am considering to apply Entity Framework in a new project because I liked its OR/M-API as well as the storage/conceptual model mapping-capabilities (plus Linq of course and Entity SQL).

But how can loose coupling be achieved betwen the UI layer and the business layer if EF entities are used as dataholders in both. If I leave the entities attached to their ObjectContext while they reside in the UI, the UI might bypass the business layer and connect straight to the database. If I detach the entities from their ObjectContext before passing them to the UI, there will be no changetracking, so I have to "replay" all changes in the business layer for them to be persisted to the database (difficult to achieve, esp. with parent-child relations). While I don't want the business layer to degrade to a "object-tree-persistence-engine", there are scenarios where having this ability would be helpful.

This certainly applies to other OR-mappers as well, but several alternative products seem to have somewhat better detaching/attaching mechanisms.

Answer 1

Google "Entity framework" and "vote of no confidence" and see what you get.

Answer 2

"Replaying" the changes is easier than you might think. Here's the general outline of what you need to do:

1. Store the "original" version of the entity instance before you detach it and hand it to the UI.
2. Let the UI do its thing.
3. When you want to persist changes made by the UI to the database, take the original version that you stored, and attach it to the EntityContext. Apply the changes from the modified version returned by the UI to this instance. Now SaveChanges. The Entity Framework will handle the three-way merge.

Answer 3

I'm not aware of any ORM that deals gracefully with n-tier solutions where you want to have platform independence. The EF works well when everything is happening within an ObjectContext, when you have an n-tier solution (physical separation, WCF/XML Web Service calls) you have to do some plumbing to get the objects behaving correctly.

You can achieve loose coupling by using a Repository pattern to separate out the api dependencies on the Ef (http://blog.keithpatton.com/2008/05/29/Polymorphic+Repository+For+ADONet+Entity+Framework.aspx). However, if you are using your EF classes within the UI layer directly, you will have a dependency on certain types like EntityReference, EntityKey and EntityObject, unless you decide to delve into the world of getting EF to behave with pure C# classes (POCO) which seems more trouble than it's worth to me.

Answer 4

Daniel Simmons, of ADO.Net team gave an extension method "AttachAsModified" to attach an object that has been modified.

That's not as smart as replaying changes, but that makes it : I'm using it into a sample project.