Entity Framework in a n tiered architecture - Best Practices to follow?

Question

I have been reading the MSDN article at http://msdn.microsoft.com/en-us/magazine/cc700340.aspx

But was wondering if there are other / alternatives best practices to using the Entity Framework (.net framework 3.5 sp1) in an asp.net , n tiered application.

Answer 1

I think that a common design pattern used with the entity framework is the Repository pattern, I won't provide links because a google search will return more than I can post here. It will help you hide your data access code behind an interface that allows for easier testing and separation of concerns.

I think that any choices you make in terms of best practice will depend heavily on the tools you're working with. if you're using standard ASP.NET then I would suggest going with the MVP pattern suggested in the article you linked to to help you separate your concerns and create testable code. However if you're using ASP.NET MVC then MVP is irrelevant as the framework helps separate your concerns for you. A little more background on your environment might help make recommendations.

Answer 2

It's worth noting that this is an area that's had a lot of attention as part of .NET 4 and EF4.

They now have support for POCOs, as well as Self-Tracking-Entities, both of which can be sent back and forth between layers and tiers (including WCF boundaries).

Take a look at this blog entry about Self-Tracking-Entities for more information.

Answer 3

I like to use the UnitOfWork pattern along with DDD and a service layer. I do not pass my domain objects to any layer other than the service layer. Even then my domain objects are abstracted by interfaces. The service layer uses an adapter pattern or remote facade pattern to pass dto objects to its clients.