Dependency injection as a pattern provides a lot of useful nudges to get you to produce easily readable and maintainable code. One way in which it does this is to make dependencies explicit so you can see exactly what services a class requires. When using Entity Framework most people are passing the whole context through as a dependency. This post explores an alternative to this approach that provides more clarity of the client code’s use of the context.
We’ve been coding with Entity Framework here at laZook for a while now, using the code first workflow. We’re using Autofac as our dependency injection framework. We inject dependencies into the constructor so that there is one clear place to view a class’s dependencies.
We used to inject the whole DbContext derived class into each type that needed to do anything with the context, e.g. add entities or save changes. This was fairly easy to do, but lead to some confusion. Let’s look at an example program using this technique:
In this simple example we saw that the
Coordinator class was calling upon a couple of worker classes and then persisting any changes. The worker classes were adding the entities to their respective
There is a problem with the code, though. If it’s a Friday, no Wotsits will be made. The code will exit due to the exception. If you were looking only at the
WotsitGenerator code, you’d be forgiven for thinking that there was a single unit of work and it would not be committed. It looks like the
Coordinator is responsible for the
SaveChanges call. However, a closer look at the
WidgetGenerator reveals a call to
SaveChanges after it has created a widget.
It’s a simple example, but where
SaveChanges is buried in larger code it can be difficult to work out what is being committed and what isn’t.
What to do about this? One answer is to ensure that
SaveChanges is only ever called at the very top level as the last action before the end of the program (in this example) or page request / job execution / button click handler. This works, but is somewhat limiting. What if you want to perform multiple
SaveChanges to checkpoint during a long running operation? What if the success or failure of one
SaveChanges determines whether or not another unit of work is embarked upon?
We need to make it clear who owns the responsibility for initiating completion of the unit of work.
The solution we’ve come up with is to create an
ICompleteUnitOfWork interface that contains the
SaveChanges method and have the context implement this interface. This interface is then declared as a dependency for the class that has the responsibility of calling
SaveChanges. This allows us to glance at a class constructor and see whether that class owns the responsibility for completing the unit of work. Elsewhere we inject
IDbSet<TEntity> instances. This helps us see which entities (or at least which aggregate roots) a class is involved in reading or editing.
Here’s the same code with the new dependencies and the errant
WidgetGenerator removed. We can clearly tell that
WidgetGenerator does not call
SaveChanges by seeing that it only takes a dependency on
What are the problems with this approach?
There are some usage patterns of Entity Framework that it doesn’t support too well, but it can be extended to do so. For example, there is no way to get at the
DbContext.Entry method for attaching objects and setting their state. You could introduce another interface for this,
IManageUnitOfWorkObjectState, but it feels clunky.
Also, injecting the IDbSets is a good first step, but I actually prefer creating some repositories on top of the IDbSets as it better allows for caching and encapsulation of common queries.
I’m interested in any development suggestions or criticisms of the ideas. Let me know here or on Twitter.