Automapper for use with Entity Framework using repository pattern?

Question

Been busy creating a new app, basically i have my dataccess, service layer and presentation layer... All works great but i am using the entity classes that are returned by EF. Problem here is i pass these onto the presentation layer so i need to add the entity framework reference /dataccess to the presentation layer - NOT GOOD:

So my idea was the following and was looking for some help and confirmation that i am going down the right lines...

1. Create a set of classes in the service layer like customer, order etc because the presentation layer has a reference to the service layer..

2. When a customer entity is returned in the dataccess i would return the entity class i.e. Customer to the service and i would do the mapping here - Not too sure if i like this?

3. where would be the best places for the these "standard classes" that i use for mapping, if i put them in the service layer and do the mapping the dataaccess then this would create a circular reference as Dataccess > service and service > dataaccess.. - it should be only one way i.e. service > dataaccess

I was thinking of using Automapper (http://www.codeplex.com/AutoMapper) to take care of this, am i on the right lines??? Any ideas or examples really appreciated..

As i say the only thing is that when i return from dataaccess to service layer (using Iqueryable) i need to map these away from the entity classes and use standard collection classes..

I think this is where i get confused, i do feel it isn't good using the entity classes because that means i need a reference to the entity framework / dataaccess in my presentation layer to be able to access the entity classes..

Answer 1

You've hit one of the weak points of EF v1. For now, yes, going the route with AutoMapper certainly allows you to convert your EF entities to "straight" business entities and use them in your higher-up layer.

Also, EF v4 which is due with .NET 4.0 / Visual Studio 2010 should bring a lot of relieve in many of the problem areas - support for your own, straight POCOs (Plain Old CLR Objects), and a great many more. Check out the EF Design Blog. The team has posted a number of very interesting, very promising posts lately, with regards to EF v4. I'm looking forward to it!

Marc