Over a million developers have joined DZone.

Using Unit of Work Pattern with Entity Framework


In a previous postUsing Unit of Work Pattern with Entity Framework
I explained how
to create a
simple repository
on top of
Entity Framework.
In this post I’ll explain the Unit of Work pattern and how
we can use it with our data access layer.

What is Unit of Work Pattern?

In his famous and developer must read book
Patterns of Enterprise Application Architecture”, Martin Fowler
defines the Unit of Work as “Maintains a list of objects affected by a
business transaction and coordinates the writing out of changes and the
resolution of concurrency problems.”
What it means is that a unit of work is a context/session/unit object that
tracks the changes of business entities during one business transaction. It is
also responsible for the manage of concurrency problems when they occur.

How to Use The Pattern?

As in the repository pattern we will start with an interface which was
suggested by Martin Fowler:

public interface IUnitOfWork<T>
void RegisterNew(T entity);
void RegisterDirty(T entity);
void RegisterClean(T entity);
void RegisterDeleted(T entity);
void Commit();

As you can see we register changes of entities inside the unit of work
and in the end of every transaction we commit it using the commit method.
In all the major ORMs out there you get all that functionality within the
session/context objects. It is the unit of work object that holds the details
of every change you do to an entity. Since this is the case you don’t
have to have all the four register methods when you use frameworks
like Entity Framework, NHibernate or other ORMs.
In my example I’m going to use the following unit of work interface:

public interface IUnitOfWork<T>
void RegisterNew(T entity);
void RegisterDeleted(T entity);
void Commit();

Entity Framework Example

Lets return to the example of the repository I used in the previous post.
I can transform the DepartmentRepository that I’ve built into a
unit of work that handle departments like this one:

public class DepartmentRepository : IRepository<Department>,
IUnitOfWork<Department>, IDisposable
#region Members

private SchoolEntities _context;


#region Ctor

public DepartmentRepository()
_context = new SchoolEntities();


#region IRepository<Department> Members

public Department GetById(int id)
return _context.Departments.
Where(d => d.DepartmentID == id).

public Department[] GetAll()
return _context.Departments.ToArray();

public IQueryable<Department> Query(Expression<Func<Department, bool>> filter)
return _context.Departments.Where(filter);


#region IUnitOfWork<Department> Members

public void RegisterNew(Department entity)

public void RegisterDeleted(Department entity)


public void Commit()


#region IDisposable Members

public void Dispose()
if (_context != null)


This is a really simple example of how to implement the pattern.
There are a lot of other examples in the web like in the following link:
Entity Framework 4.0 Beta 1 – POCO, ObjectSet, Repository and UnitOfWork


Lets sum up, every ORM that respect itself (like Entity Framework) includes
implementation for the unit of work pattern. If we want to add our abstraction
layer which include a unit of work then we need to create our implementation.
We will start with an interface such as the one that Martin Fowler suggested.
Then it is our responsibility to track changes and to persist all the work that was
done in a time period as a transaction and also manage concurrency issues. 



Published at DZone with permission of Gil Fink, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}