Where "Ado.net entity frame work" files in 3 Layer Architecture ?

Question

If I use ADO.NET Entity Framework in our project and we depend on 3-layer architecture pattern that we have ( presentation layer - business layer - data access layer ) a project for each layer

So when I make an entity model file where can I put it in the DAL or BL? If I put it in the DAL and from Presentation layer want to access a domain object in it through business layer so we need to add a reference to DAL in Presentation layer. Also how do I get that type of an object as it is created in DAL? On the other hand should I put the entity model file in Business Layer? Which is the better and why ?

Answer 1

You can place the entities in a separate class library project, for example: Common Entity Library. This library can be referenced in any other app layers. You can then work with collections across application domain.

Answer 2

As I see it the Entity Framework is your DAL. It provides the needed tools to abstract the Model objects exposed by the Entity Framework from the persistance services of a backend database.

The Entity Framework straddles both the Business Layer and the DAL from this old three layer pattern. My advice is if you going with the Entity Framework is stop thinking in terms of Presentation->Business->Data and think more in terms of View->Model.

Answer 3

Ideally, the EntityFramework generated code makes up your data layer. You would basically have some repetition then in your business layer if you needed the same sorts of objects in your business layer as you have in your data layer. Unfortunately, EntityFramework doesn't really help you at all with your business layer.

Now, you'll also read things about EntityFramework that say you can/should use it as a combined data/business layer. That violates Separation of Concerns, so I would guide you away from it, but I'm sure a ton of people do it anyway. If you wanted to move from EntityFramework to NHibernate some day, you'd be best off trying to isolate your ORM from the rest of your code base and minimize any coupling to the ORM (often through implementing something like a Repository pattern).

People who talk the language of MVC will often use EntityFramework as the Model and may or may not distinguish between a data layer and a business layer (which generally would both live in the Model). Even if you use MVC, I still believe you should decouple your data access from your business rules and business logic.