I have a ASP.net (C#) project that is using a three layer architecture. I started to use Entity Framework in my DAL and the question is to what extent classes generated by Entity Framework can be used in the Business Logic Layer?
It is a good idea to use them directly or should i create my own business objects and map to them from Entity Framework(db->O/RM->BOs)?
In my opinion, the EF objects would be mapped to yours. This has a higher development cost, but gives the added benefit of persistence ignorance and decoupling. This decoupling can translate to significant agility and real world savings in the long-run, should the business need to switch to a different persistence solution. Without the decoupling, the EF objects can become deeply embedded in the BLL and even presentation layers, requiring a huge refactoring. In such a case, the business might not even consider switching persistence solutions, which could cause the business to be less competitive.
The decision to reap this benefit at the higher development cost depends on the amount of risk the business is willing to take. I suggest you consult with the project commissioners and use your best judgement to interpret their strategic objectives in a technical way.
It should be reasonable enough to use the generated classes as your Business Objects. The generated classes are partial so you can easily extend them as you please. Sometimes I find it a nicer option however to use interfaces.
I have just started on EF 2.0 (in .Net 4.0 beta 2) and it has the facility to use POCO clases as EF entities. i.e. You can now use persistence ignorant classes in EF 2.
I think this is not fully ready yet, as I couldn't follow the presentation from PDC 2009 when working in Visual Studio 2010 beta 2 but keep a watch out for this at ADO.Net team blog.
You may want to look at the Persistence Ignorance (POCO) Adapter for Entity Framework. This is an open-source project from a member of the EF team that brings POCO support to EF 1.0. EF 4.0 will have POCO support out-of-the-box, but this project serves as a stop-gap measure until .NET 4.0 drops in 2010.