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

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

Answer 2

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

Answer 3

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.