Is there a proposed LINQ usage model between Model & DataAccess layers in a layered DDD architecture

I read Tim McCarthy's amazing book on DDD in .NET . However, in his sample application, his basic data access uses SqlCE, and he manually uses embedded SQL.

I played with some templates to use the Entity Framework, but I was stuck on how to map linq queries exactly in IRepository at a basic level of data access.

I have a specific repository implementation.

public EFCustomerRepository : IRepository<DomainEntities.Customer> { IEnumerable<DomainEntities.Customer> GetAll( Expression<Func<DomainEntities.Customer, bool>> predicate) { //Code to access the EF Datacontext goes here... } } 

In my EF model, I use POCO objects, but even there will be no native mapping between my DomainEntity.Customer object and my DataAccessLayer.Customer objects.

so I can’t just pass Expression<Func<DomainEntities.Customer, bool>> predicate as a parameter for EFContext.Customers.Where(...);

Is there an easy way to map Expression<Func<T, bool>> predicate => Expression<Func<TOTHER, bool>> predicate

Or am I all wrong about this? Any suggestions / pointers appreciated.

+7
source share
2 answers

From the code presented in your example, I assume you are not using a shared repository template?

I use EF CodeFirst (but it works for old EF) with a common repository template ... http://average-uffe.blogspot.com/2011/03/repository-pattern-with-ef-code-first.html

I don't have Expression<Func<DomainEntities.Customer, bool>> in this post, but I always have a Find method in the IRepository<T> interface.

Interface:

 IEnumerable<T> Find(Expression<Func<T, bool>> expression, int maxHits = 100); 

And implementation in abstract baserepository:

 public virtual IEnumerable<T> Find(Expression<Func<T, bool>> expression, int maxHits = 100) { return this.DataContext.DbSet<T>().Where(expression).Take(maxHits); } 

And now you can call Find on any object using the lambda expression ...

I can post a complete example, if you don't get it right, just tell me when.

+2
source

In this case, you should implement your own custom converter of one expression tree to another (possibly more than one), which fully utilizes your display logic. Usually, your expression is currently only a specification (specification template), and you must convert this specification to store the expression.

Btw. this is not true. There should not be separate objects of the data access level - the data access level must load and save domain objects directly, but EF is not fully capable of doing it right, because its display functions are limited, and it pushes its own requirements for objects. You should check NHibernate or other ORMs if you want to be serious about DDD (from the book).

+3
source

All Articles