EF6 and layered architecture

Question

I know this question come back again and again, I read a lot about it, but I can't find an answer to my question. I dont have a lot of exp on asp.net mvc but I already did a project using ef, repository and uow pattern. In my last project, I had several layers including :

• Web (project MVC)
• BLL (my business layer)
• DAL (data acces, with ef context, repository and uow implementation)

Now, I want to start a new project, with EF6. I read that uow is not need and I want to give a try. So far I understand that you must pass your dbContext to your services and your services to your controllers, am I right ? So you must have a ref to entityFramework in your service layer too ? Still right ? And because of identity implementation, you need a ref to entityFramework in your UI too. So what's the point of layer anymore ? If I read this microsoft guide , all I have to do its make a folder to my DAL and other layer ?! Dont seem right to me ... But maybe ?

I read this post too, who seem to confirm my opinion. And if you add unity and configure it in your UI, its just more ref in your UI :)

So my question is, if you must start a new project now, with EF6, asp.net MVC5, what will you do ? Am I right to want to do layer ? Or just go on with my MVC project only ?

The ONE thing I miss, is a tuto who explain step to step how to start with microsoft MVC 5 template and transform it with layer, decoupling identity, and finally no ef ref in my UI. Is this thing exist ?

Answer 1

There is no silver bullet here. Some people do it one way, some - the other. Depending on level of abstraction needed. I used to have 3 projects:

1. Web
2. Core/Business (Services)
3. Model/EF/Domain (Entity Framework context and models)

And it's fine if Web has reference to Domain or EntityFramework. Web can return EF Models (just to avoid code duplications). And if you need more complex model, you create ViewModel.

I don't recommend using UoW or Repository pattern (unless you really need it). EF context is already an implementation of UoW pattern. If you want to implement repository pattern with Entity Framework, don't expose anything related to EF in the interface eg SaveChanges(), Dispose() as in this case you will not take advantage of repository pattern benefits.

So this is how I would build typical small/medium ASP.NET MVC + EF website. But like I said, everything depends on level of abstraction needed. Abstraction level is proportional to amount of code needed to write. So think first and keep it simple. Good luck.

Answer 2

I like the repository pattern very much, since it abstracts your actual data store from your client application. The front end doesn't need to know where the data comes from, it can be either from frameworks such as Entity Framework but it could as well be a simple converted DataTable. This is a generic approach and you can reuse it for all your future projects if your repository framework has passed all your tests. This tutorial gives you a good view on how to implement the combination of UOW and Repository pattern.

Basically your client application (=MVC) doesn't need to have a reference to Entity Framework, it is sufficient for your service layer to have a reference. You then use this reference to pass your own DbContext to the repository layer (assuming that you have written a repository layer for Entity Framework), ideally through DI containers like Unity.

Of course, there is a lot of discussion about whether or not to use the repository pattern with EF (as it already is an abstraction of your database) but I think it's a good exercice of creating and using reusable components.