ProgrammerGuide.Net | Step by Step Programmer Guide


Unit of work manages in-memory database CRUD operations on entities as one transaction. It is the concept that is related to the effective implementation of the Repository Design Pattern. Let us get to know more about each of these terms in detail now.


A repository pattern is basically a class defined for an entity with the power to perform all possible database operations. To understand it even better, a repository pattern for any entity will have basic CRUD and any other possible operations related to it. Generally, a repository pattern can be implemented in the following ways, which are:

1) Non-generic repository and 2) Generic repository

  1. Non-Generic Repository: It involves the use of one repository class for each entity. For example, if you have two entities, each one of them will have its own repository.
  2. Generic Repository: It can be used for all entities meaning it can either be used with the first one or the second one or any of the rest.


Grouping of one or more operations which generally include CRUD operations into a single transaction or unit so that either all operations pass or fail is what the unit of work pattern is used for. For example, all user action based transactions such as insert/update/delete and so on are done in a single transaction instead of doing the same steps in multiple database transactions, i,e., one unit of work here involves insert/update/delete operations.

Let us look at an example of non-generic repository pattern for a “customer” entity to understand everything better:

In the above code, if we are willing to add a repository for another entity say, order, both the repositories will try to generate and maintain their own instance of the DbContext which will ultimately lead to issues in the future since DbContext will have its own in-memory list of changes of the records of the entities that are being added/updated/modified in a single transaction. This is an example of any situations where unit of work is relevant. An another possible way is, we can add another layer between the controller and customer repository which will act as a centralized store to receive the instance of DbContext. In our example, in a single transaction while adding data for the order and customer entities, the same DbContext instance will be used.

The difference between without Unit of Work and with Unit of work in our example can be understood well with the help of the following diagram:

In our example, even if one of the operations break and one of them is also not saved, the database consistency will always be maintained. So when save changes is executed it will be done for both of the repositories.

Let’s us now make some more changes in our example to understand everything better. We have added a new class called UnitOfWork and it will receive the instance of DbContext. After editing, our UnitOfWork will look something like this:

And also our Customer Repositor will be changed to receive the instance of DbContext from the unit of work class. As shown in the picture below:

Finally our controller code will look something like this:

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 all about our learning on the concept of Repository Pattern.

Please click here for related products on Amazon!


Add comment

Want to Check Celebrities News?