Unit of Work in Repository Pattern


Unit of Work is the concept related to the effective implementation of the repository pattern. To understand this concept in better way, it is important to know the concept of repository pattern. We will not get into the details of the repository pattern in this discussion. But a small idea of this concept is necessary to proceed further.

What is Repository pattern ?

A repository is nothing but a class defined for an entity, with all the operations possible on that particular entity. For example, a repository for an entity Customer, will have basic CRUD operations and any other possible operation related to it. A repository pattern can be implemented in following ways :

  • One repository per entity (non generic) : This type of implementation involves the use of one repository class for each entity. For example, if you have two entities Order and Customer, each entity will have its own repository.
  • Generic repository : A generic repository is the one which can be used for all the entities i.e. it can be either used for Order or Customer or any other entity.

What is Unit of Work in Repository pattern ?

Unit of Work is referred to as a single transaction, which involves multiple operations of kind insert/update/delete etc. To say it in simple words, it means that on particular user action(say registration on a website), all the transactions like insert/update/delete etc. are done in one single transaction, rather then doing multiple database transactions. This means, one unit of work here involves insert/update/delete operations, all in one single transaction.

To understand this concept, consider the following implementation of repository pattern using non-generic repository, for a Customer entity.

Unit of Work

The above code seems to be fine. The issue arises when we add repository for another entity, say Order. In that case, both repositories will generate and maintain their own instance of the DbContext. This may lead to issues in future, as each DbContext will have its own in-memory list of changes of the records, of the entities, which are getting added/updated/modified, in a single transaction/operation. In such a case, if the SaveChanges of one of the repository fails and other one succeeds, it will result in database in-consistency. This is where the concept of UnitOfWork comes in the the role.

To avoid this, we will add another layer or intermediate between the controller and the Customer repository. This layer will act as a centralized store for the all repositories to receive the instance of the DbContext. This will make sure that, for a unit of transaction, which spans across multiple repositories, should either complete for all entities or should fail entirely, as all of them will share the same instance of the DbContext. In our above example, while adding data for the Order and Customer entities, in a single transaction, both will use the same DbContext instance. This situation, without and with Unit of work, can be represented like following :

Unit of work in repository pattern

In above representation, during a single operation, which involves Customer & Order entities, both of them use the same DbContext instance. This will make sure that even if one of them breaks, the other one is also not saved, thus maintaining the database consistency. So when SaveChanges is executed, it will be done for both the repositories.

Let us implement this concept in our example. We add a new class called UnitOfWork and this class will receive the instance of the DbContext. The same class will further generate the required repository instances i.e. repository instances for Order & Customer and pass the same DbContext to both the repositories. So our UnitOfWork will be like the following :

UnitOfWork_2

And, our Customer Repository will be changed, to receive the instance of DbContext from the unit of work class. See the code below :

Unit of Work in repository pattern

Similarly, we can have the code for the Order repository. Finally, our controller code will be like the following :

Unit of Work in repository pattern

Here, both the Order and Customer repository use the same instance of DbContext and we are executing the save changes using the instance unit of work class. So the changes of a single transaction are either done for both or none. Run the code and see the results.

So this was about the concept of unit of work in repository pattern. Any suggestions are welcome.

Advertisements

About Jasminder

.Net developer and blogger by profession, keen to learn new technologies, love nature, music and cricket.
This entry was posted in Design and Architecture. Bookmark the permalink.

I have a suggestion..

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s