Implementing repository for EF4 using DDD and IoC

Question

I think I'm going in circles.

I'm working on an MVC 3 solution using EF4 & POCOs (database-first) and IoC. My repository and UoW patterns were mostly adopted from this article and this article.

My solution is made up of the following projects:

Implementations:

• Presentation (MVC site)
• Domain Services (business layer)
• Domain Repository (data access)
• Domain Context (my EF4 edmx and generated context)
• Domain Models (my EF4 generated POCOs)

Interfaces:

• Domain Services Interfaces (business layer interfaces)
• Domain Repository Interfaces (data access interfaces)
• Domain Context Interfaces (interfaces for generated EF4 context)

And lastly, the IoC project that ties everything together.

If you notice in that first article, the author mentions removing the dependency on ObjectSet from the domain services. This, I'm assuming, is for testability. Problem with this, though, is that it hinders the ability to do complex queries from the domain services, because IObjectSet and IEnumerable (returned by most methods on repository) don't stub out methods for complex querying.

Does this imply that I should be doing my complex querying in my repository? Should I move away from methods like public T Single(Expression<Func<T, bool>> where) and stick to methods like public T GetUserById(int id)?

If this is not the case, then how do I do complex queries such as this in my service layer?

Looking at my solution outline above and the questions I have, am I moving in the right direction, or am I creating problems for myself?

Thanks in advance.

Answer 1

Entity framework is a repository by itself. Why add an extra layer of complexity (repository). It just makes querying more difficult and you have to write all the repetitive code again and again (FindById(), FindAll(), FindAllByName() ....)

Answer 2

This is subjective/matter of opinion, but you could make your Repository return IQueryable<T>, then you can do your "complex queries" in your service like this:

return _repository // IRepository<T>
          .Find() // IQueryable<T>
          .Where(someComplexPredicate) // IQueryable<T>
          .SingleOrDefault(); // T

ObjectSet<T> : IQueryable<T>, which makes this possible.

If you want to start doing ObjectSet<T>-specific things in your service, you've got two options:

1. Expose the ObjectSet<T>-specific method as a method on your Repository interface
2. Use an IQueryable<T> extension method to do a "soft cast" to ObjectSet<T> (e.g var objSet = source as ObjectSet<T>).

Always try and go with option 1.

Perfect example is eager loading. There is a method called Include on the ObjectContext<T>, so if you use IQuerayable<T> in your Repository, how do you eager load?

Since Include takes a "magic string", you could accept this in your Find method on your Repository, e.g:

return _repository // IRepository<T>
          .Find("Product.Orders") // IQueryable<T>
          .Where(someComplexPredicate) // IQueryable<T>
          .SingleOrDefault(); // T

Fortunately in EF CTP5 they have introduced a strongly-typed Include which works off IQueryable<T>, so i didn't have to do the above when i cutover.

So as i said, best thing to do is expose methods on your Repository interface. But there needs to be a tradeoff - an interface should be a "contract" or "definition" of a service, not about the implmentation. So EF-specific things should be done via extension methods. General things can be done via the repository interface.