Entity Framework in layered architecture

Question

I am using a layered architecture with the Entity Framework. Here\'s What I came up with till now (All the projects Except UI are class library):

• Enti

Answer 1

BLL: Business Logic Layer. Will implement repository pattern on this layer

I don't really agree with this. Repository is meant to abstract the underlying data store (SQL Server, XML, etc). It's a data layer concern, not a business one - therefore why should it be in the BLL?

Is my layer discintion approach correct?

Kind of. :) It's a bit subjective, but generally you have:

• Data
  • Repository goes here.
• Business
  • Business rules, domain logic, and entities.
• Presentation
  • UI/web application.

Now, usually those three are broken up further. So in your case I would have:

1. MyCompany.MyProject.Data (Repository)
2. MyCompany.MyProject.Business.Services (calls repository, applies business rules, etc)
3. MyCompany.MyProject.Business.DomainModel (Entities)
4. MyCompany.MyProject.UI (Web app)

Should I take any additional steps to perform chage tracking, lazy loading, etc (by etc I mean the features that Entity Framework covers in a conventional, 1 project, non POCO code generation)?

If you're not using POCOs (e.g your using default code generation). Then you don't need to worry about change tracking.

As for lazy loading - that is a decision you need to make. I personally disable lazy loading, because I don't want lazy developers returning a bunch of records when they didn't ask for it.

Instead, force the calling code (e.g the business/service) to eager load what it needs.

If your using a ASP.NET MVC application, if you have lazy loading on, your View could end up calling the database at render time, breaking the MVC pattern.