Questions regarding Entity Framework + DDD

Question

I'm having a difficult time finding straight forward examples of using EF in a DDD style pattern. This is also my first time employing DDD and have a few questions regarding solution layout and how to employ some of the DDD patterns.

1) Most of the examples I've seen regarding using the Repository pattern w/ EF just show specialized Model interfaces such as IContactRepository and then a concrete type implementing the interface. Ideally, I'd love to use something like IRepository that has a basic set of functionality for CRUD ops. I could then create specialized repositories if if necessary such as IContactRepository : IRepository when necesary as most of my models won't need to be extended. Am I barking up the wrong tree? Can someone provide me w/ examples of this style of implementation?

2) Right now I have my solutio broken up into the following three projects: Models (contains my EDM), Repositories, and Services. Is this fitting or is there another layout approach I'm not considering and should be?

3) I've seen examples of repositories having a Query(Func<T>)/Query() methods that return IQueryable. Is this smelly or something frowned upon?

Thanks!

Answer 1

Here is a sample:

http://dataguidance.codeplex.com/

Answer 2

We are currently using EF with DDD, but I would have to say that in its current implementation, EF isn't very suitable to this kind of architecture. The main problem is that the only way EF currently works is by having each 'Entity' derive from an EF-specific base class.

On the other hand, the whole point about Repositories is to abstract away the data access technology. The whole idea behind DDD is that the Domain Model should be unconstraind by implementation details such as the choice of data access technology. This means that domain objects should be defined so that they are Persistence-Ignorant.

In other words: You can't use the EF 'Entities' as domain objects, so in your DAL, you must manually write a lot of code that maps to and from the domain objects to the EF 'Entities'. That gets tired really fast.

I would definitely consider having IQueryable on a Repository to be a leaky abstraction, and it doesn't make a lot of sense in DDD parlance. If domain objects are cohesive units, it doesn't make a whole lot of sense selecting only certain 'columns' from them.

In EF for .NET 4.0 we will get Persistence Ignorance, so it should become better in the future...