Using Repository and Unit of Work patterns with Entity Framework 4.0

Visit msdn.com/data/ef for the latest information on current and past releases of EF.

If you have been watching this blog, you know that I have been discussing the various aspects of POCO capabilities we added to Entity Framework 4.0. POCO support makes it possible to do persistence ignorance with Entity Framework in a way that was never possible with Entity Framework 3.5.

If you missed the series on POCO, I’ve listed them here for your convenience. It might be a good idea to quickly check these out.

In this post, I’d like to look at how we might be able to take our example a bit further and use some of the common patterns such as Repository and Unit Of Work so that we can implement persistence specific concerns in our example.

Expanding on our Northwind based example a bit further, let’s say I am interested in supporting the following Customer entity oriented operations:

Query for a customer by ID

Searching for Customer by Name

Adding a new Customer to the database

I also want to be able to query for a product based on ID.

Finally, given a customer, I would like to be able to add an Order to the database

Before we get into the details, there are two things I’d like to get out of the way first:

There is more than one “correct” way to approach this problem. I’ll likely be making many simplifying assumptions as I go – the objective is to show a very high level sketch of how you might implement the two patterns to solve the problem at hand.

Normally, when using TDD, I’d start out with tests and use my tests to evolve my design incrementally. Since I’m not following TDD in this example, please bear with me if you see me doing things like defining an interface upfront, instead of letting tests and commonalities dictate the need for an interface, etc.

Implementing the Repository

Let’s start with the work we have to do on Customer entity and look at what a repository for dealing with Customer might look like:

publicinterface

ICustomerRepository

{

Customer

GetCustomerById(string id);

IEnumerable

<

Customer

> FindByName(string name);void AddCustomer(

Customer

customer);}

This repository interface seems to meet all the requirements around Customer:

GetCustomerById should allow me to get a single customer entity by primary key

FindByName should allow me to search for customers

AddCustomer should allow me to add customer to the database

This sounds good to me for the moment. Defining an interface like this for your repository is a good idea, especially if you are interested in writing tests using mocks or fakes and it allows for better unit testing by keeping your database out of the equation entirely. There are blog posts coming in the future that cover testability, mocks and fakes, etc.

You might take this interface definition a bit further and define a common IRepository for dealing with concerns that are common for multiple repository types. This is fine thing to do if you see that it works for you. I don’t necessarily see the need yet for this particular example and so I’ll pass on it for now. It is entirely possible that this becomes important as you add more repositories and refactor.

Let’s take this repository and see how we might build an implementation of it that leverages Entity Framework to enable data access.

First of all, I need an ObjectContext that I can use to query for data. You might be tempted to handle ObjectContext instantiation as a part of the repository’s constructor – but it is a good idea to leave that concern out of the repository and deal with that elsewhere.

Here’s my constructor:

public CustomerRepository(

NorthwindContext

context){if (context == null)thrownew

ArgumentNullException

("context");

_context = context;}

In the above snippet, NorthwindContext is my typed ObjectContext type.

Let’s now provide implementations for the methods required by our ICustomerRepository interface.

GetCustomerById is trivial to implement, thanks to LINQ. Using standard LINQ operators, we can implement GetCustomerById like this:

Note that I chose to expose the results as IEnumerable<T> – you might choose to expose this as an IQueryable<T> instead. There are implications to doing this – in this case, I am not interested in exposing additional IQueryable based query composition over what I return from my repository.

And finally, let’s see how we might implement AddCustomer:

publicvoid AddCustomer(

Customer

customer){ _context.Customers.AddObject(customer);}

You may be tempted to also implement the save functionality as a part of the AddCustomer method. While that may work for this simple example, it is generally a bad idea – this is exactly where the Unit of Work comes in and we’ll see in a bit how we can use the this pattern to allow us to implement and coordinate Save behavior.

Here’s the complete implementation of CustomerRepository that uses Entity Framework for handling persistence:

For dealing with my Product and Order related requirements, I could define the following interfaces (and build implementations much like CustomerRepository). I’ll leave the details out of this post for brevity.

publicinterface

IProductRepository

{

Product

GetProductById(int id);}

publicinterface

IOrderRepository

{void AddOrder(

Order

order);}

Implementing Unit of Work Pattern using ObjectContext

You may have noticed this already; even though we didn’t implement any specific pattern to explicitly allow us to group related operations into a unit of work, we are already getting Unit of Work functionality for free with NorthwindContext (our typed ObjectContext).

The idea is that I can use the Unit of Work to group a set of related operations – the Unit of Work keeps track of the changes that I am interested in until I am ready to save them to the database. Eventually, when I am ready to save, I can do that.

I can define an interface like this to define a “Unit of Work”:

publicinterface

IUnitOfWork

{ void Save();}

Note that with a Unit of Work, you might also choose to implement Undo / Rollback functionality. When using Entity Framework, the recommended approach to undo is to discard your context with the changes you are interested in undoing.

I already mentioned that our typed ObjectContext (NorthwindContext) supports the Unit of Work pattern for the most part. In order to make things a bit more explicit based on the contract I just defined, I can change my NorthwindContext class to implement the IUnitOfWork interface:

publicclass

NorthwindContext : ObjectContext, IUnitOfWork

{ publicvoid Save() { SaveChanges(); }

. . .

I have to make a small adjustment to our repository implementation after this change:

That’s it – we now have our IUnitOfWork friendly repository, and you can use the IUnitOfWork based context to even coordinate work across multiple repositories. Here’s an example of adding an order to the database that requires the work of multiple repositories for querying data, and ultimately saving rows back to the database:

IUnitOfWork

unitOfWork = new

NorthwindContext

();

CustomerRepository

customerRepository = new

CustomerRepository

(unitOfWork);

Customer

customer = customerRepository.GetCustomerById("ALFKI");

ProductRepository

productRepository = new

ProductRepository

(unitOfWork);

Product

product = productRepository.GetById(1);

OrderRepository

orderRepository = new

OrderRepository

(unitOfWork);

Order

order = new

Order

(customer); order.AddNewOrderDetail(product, 1);

orderRepository.AddOrder(order);

unitOfWork.Save();

What’s quite interesting to see is how little code we had to write in order to enable data access using Repository and Unit of Work patterns on top of Entity Framework. Entity Framework’s LINQ support and out of the box Unit of Work functionality makes it trivial to build repositories on top of Entity Framework.

Another thing to note is that a lot of what I’ve covered in this post has nothing to do with Entity Framework 4.0 specifically – all of these general principles will work with Entity Framework 3.5 as well. But being able to use Repository and Unit of Work like I have shown here on top of our POCO support is really telling of what’s possible in Entity Framework 4.0. I hope you find this useful.

Lastly, I’ll reiterate that there are many ways of approaching this topic, and there are many variations of solutions that will fit your needs when working with Entity Framework, Repository and Unit of Work. You might choose to implement a common IRepository interface. You might also choose to implement a Repository<TEntity> base class that gives you some common repository functionality across all your repositories.

Try some of the various approaches and see what works for you. What I’ve covered here is only a general guideline – but I hope it is enough to get you going. More importantly, I hope this shows you how it is possible to use the POCO support we have introduced in Entity Framework 4.0 to help you build a domain model that is Entity Framework friendly without needing you to compromise on the basic principles around persistence ignorance.

The project that includes some of the code I showed is attached to this post. Stay tuned as we’ll likely have more to say on this topic when we discuss unit testing, TDD and testability in one of our future posts.

This post covers the basic patterns used when applying Domain-driven design DDD.

Domain-driven design provides a set of pattern to define domain objects and to access them in a simple way.

Working with Domain-driven design sets the focus on the domain so you try to learn as much as possible about the domain and you try to put that new knowledge into the code. It avoids the gaps between business expert and developer.

In the last 2 years, I have been working with the newest .Net technologies (Entity Framework 3.5 and Linq2Sql) and methodologies (DDD Patterns) to find a way to simplify the creation of Data Access Layers.

The result of my work is a common library that supports the developer in the folowing steps in creating a flexible Data Access Layer (DAL)

– Simplifies the using of an ORM

– Uses LINQ for querying data

– Supports DDD patterns

– Enables and simplifies TDD

– Expandable by any data source supporting Linq

– Supports Linq2Entities and L2Sql (NHibernate support planned)

– Enhances missing functionalities to EF and Linq2Sql

If you are interested in that library and if you are familiar with DDD, you are free to use this library to combine the newest ADO .Net technology with the DDD pattern.

If you have this as the first line then there is little point in abstracting away a repository or unit of work to be honest as you have a direct dependency on the object context and therefore the EF. You should also use some form of injection to abstract away the repository and unit of work implementation?

First of all thanks for the post. I have a question regarding your use of the Repository pattern. If I understand correctly the purpose of the Repository is to map between your DAL and LOB to ensure true persistance ignorance. But if you return an instance of an EF Entity object as in the example below;

@Keith Patton – you probably already know this but for anyone else wondering about your comment on IUnitOfWork unitOfWork = new NorthwindContext();

I guess its left to the reader to use an IoC container of ther choice rather than explitly creating a NorthwindContext. For example Unity would let you configure a mapping for IUnitOfWork to the concrete NorthwindContext.

Of course this should also probably be extended to include the Repositiries.

You would inject IUnitOfWork, ICustomerRepository and IProductRepository into your application layer object, e.g a Controller, Presenter or Service. (preferably through the ctor)

The key would be to configre the lifetime of the UOW to be per request. This way each repo will use the same UOW/transaction.

You may choose to let the UOW be handled by the infrastructure layer, and not inject it at all. If the request is good, it will commit/save, else it will rollback. (you shouldnt have to deal with that really)

You would inject IUnitOfWork, ICustomerRepository and IProductRepository into your application layer object, e.g a Controller, Presenter or Service. (preferably through the ctor)

The key would be to configure the lifetime of the UOW to be per request. This way each repo will use the same UOW/transaction.

You may choose to let the UOW be handled by the infrastructure layer, and not inject it at all. If the request is good, it will commit/save, else it will rollback. (you shouldnt have to deal with that really)

imagine that we have a domain object with the EF Model in it and in my Interface Layer, Business Layer and Data Access Layer I have to reference it, why? because we don’t have the POCO objects and the database access in different objects.

In my presentation layer I reference the project with the EF model and if I want I can do LINQ there to acess the data.

I would like to create DTO objects to all database entities and create some how mapping from the EF Domain and my application domain…..

Hi, just curios, why does the CustomerRepository take an IUnitOfWork? I thought that repositories should not care about the unit of work. CustomerRepository is a concrete class, why not just have it accept a NorthwindContext? Its just an implementation detail anyway. And besides its being casted immediately back to a NorthwindContext in the constructor and the IUnitOfWork interface is never used inside that class.

This example is a mess up. ObjectContext already does what the "UnitOfWork" presented in this example does, all you've done here is call ObjectContext's SaveChanges() in the "UnitOfWork"'s Save() method.. I think MS is trying to fit already established enterprise patterns in wrog places, to impress young enterprise architech wannabes, maybe?.. I've come here to see a concrete example of Unit Of Work pattern in .net, but it's just fake..

if there is an error in one of the repositories ,when we call the SaveChanges() none of the entries are saved. But they remain in memory and will be saved along with another code executing with the same instance of unit of work. how can we prevent this from happening?

@Exception Handling – This is usually what you want within a UnitOfWork, it represents one set of changes that will be applied to the database. If you want to isolate the changes made within one part of the application I would suggest using a separate UnitOfWork. Would that work in your scenario?

I can see no one didn't reply to Ilya (DI/IoC related) about resolving IUnitOfWork, ProductRepository, OrderRepository. I've been trying to do that for a while (using Unity) but without any luck. Any chance for some help?

Thanks.

btw. if I remove IUnitOfWork part out of the picture resolving becomes fairly simple. Of course I don't wont to do that.

@vissahid – It's just that this post is over 5 years old and the theme of our blog has changed since this was posted. Per the header on this post, the content here is about EF4 and we are now up to EF6.1, so it is all out-of-date. We don't go back and keep formatting etc. updated for posts that are outdated (other than putting in the header to let readers know it is out of date).