views:

191

answers:

2

Hi All,

I am writting a new application using the Entity Framework.

Where would the EF lie? My current thinking is to issolate it in a DataAccess assembly that exposes a number of repositories (that essentially wrap EF).

I would then create my own Domain objects and pass them to the repository that maps them to an EntityFramework Entity (which I treat as a DAO).

The problem with this approach is the amount of mapping I would need to do, even for a smaller domain model.

I also like the Repository.GetAll(Func filter) approach to retrive a filtered number of items, however I would need to convert the function to take a DAO instead:

Func<TDomainObj, bool> filter ---> Func<TEntityFrameworkObj, bool> filter

Not sure how I could do that? If I simply allowed Func on the repository, the caller would have to know about System.Data.Objects.

Im starting to think I should just couple the app to EF and use their System.Data.Objects as my model....

Look forward to your suggestions/comments,

David

A: 

We encapsulate EF behind a service layer. The service layer exposes DTO objects. We map the EF objects to DTO objects in code.

In some cases we do a get by template, which is similar to what you are doing. Where we send in a object, for example a customer and get back all customers that look like the one we sent in.

Shiraz Bhaiji
A: 

Julie Lerman has a free, online presentation on EF tips and tricks tomorrow.

I will be presenting "How to Think Like the Entity Framework (and why you might want to bother doing so in the first place)" at the free, online CodeRage conference in September. The presentation will be available for download shortly thereafter.

Craig Stuntz
Thanks for the information, I watched Julies presentation :) I will keep an eye open for yours... very helpful with all this :)
David Kiff