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:
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.
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:
Now, usually those three are broken up further. So in your case I would have:
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.