What is proper abstraction using Entity Framework in webforms

Question

I am trying to find a good way to develop my solution. I know that I will use the following technologies: Asp.Net Webforms and Entity Framework 4.1. My EF model is based on an existing database. I plan to use the EF DbContext generator to build my context and objects. And this is the moment when things get a little complicated for me.

I want to have a proper separation of problems, providing better testability and allowing me to separate my business logic from my DAL. My solution now has three projects: Web, Core and Data. I would like the dependencies to be Web -> Core <- Data, without any dependencies between the Web and the data. This requires that my entities actually exist in Core, not Data (where my edmx is). Currently, I decided to move the Entities.tt file to Core and change the inputFile to point to my edmx in Data to create my Entities in Core. But I'm not sure what to do with the Context. It depends a lot on EF, and so I don’t just want to move this to Core. I was thinking of an interface, creating my own IEntities.Context.tt and deleting it in Core. I am concerned about the loss of functionality if my interface does not create DbSets and DbContext.

Two thoughts that I had on this: 1) put a link to System.Data.Entity in Core, 2) do not use DbSet and replace it with ICollection (or some such common container) and wrap DbContext as just an object in my interface.

Any insight would be greatly appreciated. Thanks.

Answer 1

There are many different templates that you could use, but they immediately come to mind:

1) Add a business / service level - this will abstract between your data level and presentation level. This is the approach I take most often - using AutoMapper and Dependency Injection (I like Ninject) to make it easier for the monkey to work. Your business layer will reveal either its own version of your database objects (not recommended) or objects related to your business model (more reliable approach).

2) The use of the "Invert control template" template is very popular at the moment, although I still have to give it bash in a real-life script. This seems to be very good for TDD / mocking etc. This basically means that your data layer depends on your business layer, and not vice versa.

FYI - My "Core" or "Common" assemblies do not know anything about my business or data layers - they just provide platform agnostic helpers and common classes - if I want to create common MVC functions, for example, I will create Company.MVC.Core instead .

Answer 2

If your solution is completely green, I like to use the first code approach in the entity structure (goodbye to the shameless plugin, but I posted a tutorial on my blog about this http://www.terric.co.uk/code-first-entity-framework-and -sql-migrations / ). I like the control it gives me, which I cannot get when I create .edmx.

Moving to the structure, I usually separate the layers of my project into separate assemblies: Domain (and Data) and WebUI, structured with the following folders (namespaces):

Domain (business layer and data layer assembly) Data (contains my EF data context and Interface to the context) Entities (contains my POCO objects for the context) WebUI (presentation layer assembly) Infrastructure (contains my dependency inject initialiser) 

I never make my entities and instead use concrete in my presentation layer, however in the context I will always use DI, as I may need / use ADO.Net (especially for legacy applications), where my domain will still use ADO .Net to read / write my POCO objects. That way, when I end up getting the opportunity to implement ORM with my legacy application, I can just DI the ORM version of my domain.

As a note to this, if you followed the repository pattern, you can always link them and DI your repositories. In any case, your POCOs must be specific to the solution, so the underlying data structure will not change dramatically, so I never do them.