Question

I would like to create a DataAccess / DataLayer project and encapsulate EF there, so that my MVC project doesn’t know that I’m actually using EF. I may decide to use NHibernate in the future, and the out-of-the-box MVC project created by Visual Studio adds EF referece/DLL to the web project.
I cannot access the DbContext from MVC of course, because it needs EF reference.

As a result I wouldn’t be able to use Code First data annotations, due to EF being required.

Is it worth creating a repository, or should I keep it “simple” and add EF reference to my MVC project?

It just doesn’t make sense to me that I need to add a reference to EF to all my projects, tests and clients that use the context/database.

Thanks

Answer 1

What you are trying to create is the typical layer pattern. At the top you have the Presentation Layer, in the middle you have your Business Layer, and at the bottom (or last layer), you have your DAL layer.

How you design your layers is completely up to opinion and need, but the way I described it above requires you to have 3 different projects. A MVC project, a Logic project, and a DAL project. The DAL project will contain your EF reference and your repository objects. It’s then up to you to convert your DbContext/ObjectContext items to POCOs to use them in the business layer. The business layer would know about EF (depending on how you pass your EF objects around), but the business layer would then pass it’s own objects (mapping them from your DAL layer objects) to MVC — thus completely decoupling EF from the MVC layer.

If you are going to use this type of pattern, you should go a step further and include Dependency Injection with a bootstrapped container (crosscutting project using Unity Framework, or something like that).

See Microsoft Pattern & Practices, http://msdn.microsoft.com/en-us/library/ff650706 (Chapter 25 is a good example of layering).

HTH