Entity Framework in layered architecture

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):

• Entities: The POCO Entities. Completely persistence ignorant. No Reference to other projects. Generated by Microsoft's ADO.Net POCO Entity Generator.

• DAL: The EDMX (Entity Model) file with the context class. (t4 generated). References: Entities

• BLL: Business Logic Layer. Will implement repository pattern on this layer. References: Entities, DAL. This is where the objectcontext gets populated: var ctx=new DAL.MyDBEntities();

• UI: The presentation layer: ASP.NET website. References: Entities, BLL + a connection string entry to entities in the config file (question #2).

Now my three questions:

1. I开发者_StackOverflows my layer discintion approach correct?

2. In my UI, I access BLL as follows:

   var customerRep = new BLL.CustomerRepository();

   var Customer = customerRep.GetByID(myCustomerID);

   The problem is that I have to define the entities connection string in my UI's web.config/app.config otherwise I get a runtime exception. IS defining the entities connectionstring in UI spoils the layers' distinction? Or is it accesptible in a muli layered architecture.

3. 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)?

Thanks and apologies for the lengthy question.

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.

1) Layers seem fine to me

2) Dont see a problem with the connection string being in your UI app.config. Has to be defined someplace. You could copy your DAL.config to your application BIN folder that likely had the connection string created in it when you created the project but that to me would not seem right. I would personally manage it in your UI layer app.config

The problem is that I have to define the entities connection string in my UI's web.config/app.config otherwise I get a runtime exception.

The connection string is always picked up from the app.config/web.config of the executing appDomain (here your asp.net app and not the DAL). So wat you can do is create a xml file for storing settings in your DAL project and read those settings using xml classses provided by dot net framework