Question

I am just beginning to learn Entity Framework (starting with 5.0) and running into some issues. After watching a few videos on Pluralsight, I decided to get creative and created an abstract base class that inherited from DbContext and exposed a single “DataContext” property that was a DbSet of a generic type. Something like this:

public abstract class BaseDataContext<E> : DbContext
     where E : CustomEntity
{
      public DbSet<E> DataContext {get;set;}

      public BaseDataContext()
      {
           Database.SetInitializer<BaseDataContext<E>>(null);
      }
 }

This seemed to be working great until I started dealing with entities that had relationships with each other (parent/child). What was occurring is when I tried to add a new child entity to the database via a data class that inherited BaseDataContext is instead of just attaching the reference (meaning, taking the child and say “your parent key is 123”), it created another record with a new key for the parent and all other fields duplicated and made this new record the parent of the child. I tried just setting the key property of my child (nulling out the property that was exposed with the data), but that didn’t change anything. I found a thread on SO (here) that said it wasn’t a good idea to do multiple data contexts like what I was attempting to do and seemed to explain exactly what was happening.

My question for this is, with the popularity EF seems to be gaining for everyone, is this the common approach? To create a single data context that is then passed around with constructors everywhere? Or is there a simpler way that is more common? This would especially apply if things get into background threads since passing a context there might get difficult.

Thanks in advance!

Answer 1

You get the most out of EF, as any tool, when you use as intended. So it’s good you ask. Entity Framework, especially code-first, is all about persistence ignorance (explained here for example). I don’t know what your comment “like you would’ve done before EF/L2S” refers to, but it sounds like active record. That’s not the way to go.

The context is responsible for materializing entities from the store, tracking changes and saving changes to the database. In more detail: the context manages the unit of work (tracking changes) and it’s DbSet members serve as basic repositories (materializing and saving). The entity classes themselves know nothing about this. (As a side note: in the ObjectContext API they do, but they can be coded against as persistence ignorant).

Now about “multiple contexts”. The question you refer to is about multiple context instances of the same context type. Your question is about multiple context types (and, necessarily, multiple instances). Let’s sort this out:

• Number of context types: It is common to have a very limited number of context types, often even just one. Why? Because a context covering a large part of the database is able to retrieve and persist many different object graphs. So it serves a large number of use cases, present and future, stable and changing, but it is stable itself. It only changes when the database changes, not when the application changes. (I should say though that there are advocates of one context type per use case, but I’ve found it to be inevitable that they have a large number of classes in common, very confusing).
• Number of context instances: this issue cannot be fully covered in a few words, but it should be kept in mind that a context (1) caches data and (2) tracks and stores changes. So long-lived contexts soon contain stale data and they grow in size as changes occur. The consensus is to keep contexts “short” lived, but what is short? It could be one instance per http request, one per service call, one per (business) transaction, but also one per form in an MDI interface, one per thread… See a useful discussion on Linq-to-Sql contexts here, the same goes for EF contexts (or NHibernate sessions for that matter). One thing is clear: don’t use one static context, as some people are tempted to do.

So be as creative as you can, experiment as much as you can. Use EF as it is intended to and have lots of fun!