We are starting a new web project using C# / MVC4 and Entity Framework 5 for data access. I've decided to go with an n-layered approach for the structure of the project and I would like some feedback on my design decisions.

After doing some research on using Entity Framework in web projects, the general consensus is that there should only be one DbContext/ObjectContext per request. So to create and dispose the single context for each request, I've written an HttpModule that injects the DbContext into the HttpContext.

This example is more of a pass-through for the DAL repository, but adding a business logic layer won't be a problem. I'm choosing to return IQueryable<T> from the BLL because we are using some third party tools that require an IQueryable<T> for deferred execution.

\$\begingroup\$I like how you structured the project. Can you provide more details or articles?\$\endgroup\$
– lbrahimMay 20 '14 at 8:30

\$\begingroup\$We have just released an application for a customer mostly using this guideline. However we've just faced a dilema : We need som kind of variable scope per request and the HttpCurrent is not an option in this kind of architecture when we are in Domain. I curious if you have any solution for this need ?\$\endgroup\$
– Guillaume RAYMONDSep 13 '16 at 13:42

Service layer:
How do you plan to inject a mocked repository into your Logic Layer when unit testing it?
Wouldn't it make sense to inject these dependencies in via the constructor into your services once you've registered them in your dependency injection container?

Another issue is that sometimes a service class will need to consume many repositories in order to do its work..Not sure how you intend to handle those scenarios given that they appear to only use a single repo.

Presentation layer:
Same again, inject the dependancy on the admin service and register it in your container and have your controller factory build your controllers for you.

1: Generic DAL and Repository classes. In my view this is a big mistake. you are guaranteed to need some GetModelsBySpecialCriteria Method at some point which will force you to jump through hoops trying to define it in your generic way. The reason for the repository is to hide all the stuff you have to do to get the data away from the calling class. Not to provide a query language for calling classes.

2: Generic BLL classes. It looks like you are just repeating the DAL layer? what if your logic requires multiple repositories?

Somewhere in your project you will have actual requirements to implement. these will be effectively random and open to constant change. You dont help yourself by creating an extra generic framework to cram them all into.

How To do it right: (short version)

You already have EF (although i hate it) this provides your generic query DB DAL layer. hide it behind a repository! calling classes should not have to construct queries.

Models : Should have no external dependencies.

Business logic : two choices. OOP - hide it in Model methods, ADM - put it in services, keep models as data structs.