To explain this definition, let’s take a look at this code:
This is the concept of Unit of Work Design Pattern. The dbContext is simply an aggregator that handles its child entities in terms of inserting, reading, updating and deleting in-memory records and committing those records at once while resolving concurrency issues.
Think of a database that has tables in it. The database is the aggregate root to its tables.
Why is it called Unit of Work?
From the application designer's point of view, a Unit of Work is a sequence of actions that needs to be complete before any of the individual actions can be regarded as complete. To ensure data integrity, a unit of work must be atomic, consistent, isolated, and durable.
Actions such as inserting several records to 1 or more entities before finally commit/save those records is 1 unit of work.
Why do we use Unit of Work?
- Track changes in persistent objects
Efficient data access, manage concurrency problems, and manage transactions.
- Logical Transactions
In a web application where bandwidth is expensive (most especially in mobile devices), as much as possible we want limit multiple round trips to perform updates on a data store. This is all about efficiency. All computational requirements or steps involved will be completed first before final commit will happen to the data store.
- Testability
While it is true that DbContext is enough to implement Unit of Work, the problem is testability. We need several abstractions to solve this problem.
In this example, we are going to build a simple payroll using Console Project. This is of course the way to do payroll but we use it the purpose of demonstrating Unit of Work.
What does it do?
- It can add employees with the corresponding department, it could be in batch and commit at once;
- Compute Net Pay in batch and commit at once.
- Visual Studio 2013
- C#
- EF 6.1 Database First approach
- LINQ
- SQL Server
- Repository Pattern using Generic
- Dependency Injection
Entity Data Model (EmployeeModel)
UML Class Diagram
Participants
| Interface/Class | Function |
|---|---|
| IUnitOfWork | An interface that defines the methods and entities to be implementation by SQLUnitOfWork |
| IGenericRepository | An interface that defines the methods CRUD methods to be implemented by the entities(SQLRepository). Generic Repository is best when there are repetitive data access of different entitites. |
| SQLUnitOfWork | Concrete implementation of IUnitOfWork. |
| SQLRepository | Concrete implementation of IGenericRepository. |
| EmployeeContext | The Data Model of Employees (Entity Data Model) . |
| Department | A POCO Class for storing Department data. |
| Employee | A POCO Class for storing Employee data. |
| Payroll | A POCO Class for storing Payroll data. |
The Codes
IUnitOfWork.cs
IGenericRepository.cs
SQLRepository.cs
SQLUnitOfWork.cs
Program.cs
Your comments please!
