UNIT of Work Design Pattern

Start from the beginning
                                        

ATOMIC. In other words it’s very much possible that many CRUD operations will be equal to 1 unit of work.

So this can be achieved by using simple transactions?

Many developers can conclude that the above requirement can be met by initiating all the CRUD operations in 1 transaction. Definitely under the cover it uses database transactions (i.e “TransactionScope” object). But unit of work is much more than simple database transactions, it sends only changes and not all rows to the database.

Let me explain you the same in more detail.

Let’s say your application retrieves 3 records from the database. But it modifies only 2 records as shown in the below image. So only modified records are sent to the database and not all records. This optimizes the physical database trips and thus increases performance.

In simple words the final equation of unit of work is:-

 Collapse | Copy Code

1 Unit of work = Modified records in a transaction

So how can we achieve the same?

To achieve the same the first thing we need is an in-memory collection. In this collection we will add all the business objects. Now as the transaction happens in the application they will be tracked in this in-memory collection.

Once the application has completed everything it will send these changed business objects to the database in “ONE TRANSACTION”.   In other words either all of them will commit or all of them will fail.

C# Sample code for unit of work

Step 1:- Create a generalized interface (IEntity) for business objects

At the end of the day unit of work is nothing but a collection which maintains and track changes on the business objects. Now in an application we can have lots of business object with different types. For example you can have customer, supplier, accounts etc.  In order to make the collection reusable across any business object let’s generalize all business objects as just “ENTITIES”.

With this approach we make this collection reusable with any business objects and thus avoiding any kind of duplicate code.

So the first step is to create a generalized interface called as “IEntity” which represents any business object in our project.

This “IEntity” interface will have an “ID” property and methods (insert, update, delete and load) which will help us to do the CRUD operation on the business object. The “ID” property is a unique number which helps us uniquely identify the record in a database.

 Collapse | Copy Code

public interface IEntity

{

int Id { set; get; }

void Insert();

void Update();

List<IEntity> Load();

}

Step 2:- Implement the “IEntity” interface

The next step is to implement the “IEntity” in all our business objects.  For example you can see below is a simple “Customer” business object which implements “IEntity” interface. It also implements all CRUD operations. You can see it makes a call to the data access layer to implement insert, update and load operations.

 Collapse | Copy Code

public class Customer : IEntity

{

UNIT of Work Design PatternWhere stories live. Discover now