User-1179452826 posted
The thing with architecture issues like this is that there are many more than one way to skin a cat.
It depends on what you need, really. EF v1 (and EF v4.0) is great at simple two tier designs. You create a context and the context does all the change tracking.
Unfortunately, that's not really extensible, flexible, testable yadda yadda. EF v4.0 rectifies this a lot.
In EF v4.0, you have support for the "previous" two tier design, as well as proxy tracking. The most attractive feature though is pure POCO support. For a domain driven design, I'd use POCOs along with a repository and unit of work pattern to abstract away
anything related to EF specifically. I'd call the repository from my domain layer to carry out persistence tasks. I guess in this way, the domain layer is very storage-tech agnostic and testable, and the influence of EF or any other persistence tech won't
cross the repositories into the domain layer. This will enhance the previously mentioned yadda yadda parts.
You might want to take a look at the kigg project source code at codeplex. Kazi Manzur has done a pretty decent job with the architecture there.
But again, there are more ways to skin a cat [:)]