Table of content
- Given problem
- Solution of Unit of Work pattern
- When to use
- Source code
- Benefits & Drawback
- Application and Examples
- Wrapping up
When we want to have some CRUD operations with domain model, we will have to use Repository pattern or Data Access Object pattern to interact with database. Then, obviously, we always have a lot of small database calls.
The cost of interacting with database is very high, because we have to create session for each user, and the time to access database in HDD. It takes so much time.
For example, in DDD architectural pattern of e-commercial site, we have an aggregate root Order that contains Address, and OrderItem.
We want to persistent Order aggregate root to database. It means that Address, and OrderItem Domain Model are also persistented to database. If we have encountered some exceptions when pushing them into database, we need to revert all operations to make the consistency - one of the ACID properties in RDBMS, satisfied.
But, normally, we will iterately insert each domain model into our database. It makes our data lack the consistency property when coping with some mistakes.
So, how do we overcome this problem?
Solution of Unit of Work pattern
Solve the above problem
To ensure the consistency property of database when we have all requests that are relevant together, we will use Unit of Work pattern.
Introduction to Unit of Work pattern
According to website https://martinfowler.com, we have its definition:
Maintains a list of objects affected by a business transaction and coordinatess the writing out of changes and the resolution of concurrency problems.
And if we want to know about the position of
Unit of Workpattern, we can refer to the following image:
It means that we merge multiple operations of database into a single batch to improve the performance of system. This is one of the many ways to get the high performance in Data Access Layer with Hibernate.
When to use
Used in Domain Driven Design
When we have a set of requests and we want all requests that have to be completed in one transaction. If one request is failed, all the rest of requests will be disactive.
Benefits & Drawback
improve the performance of system when we are working with bulk of data, not iterately each record.
Because this pattern reduces the amount of calls to the database, and the round-trip networks.
It’s really suitable for DDD because our Aggregate object will contains multiple Domain Models. Then, we need to consider the persistence operations for this Aggregate object as one operation.
Application and Examples
The concept of Unit of Work is a central concept of ORMs and has been described by Scott Ambler.
Examples of Unit of Work pattern are:
DbContextclass represents a combination of the Unit of Work and Repository patterns such that it can be used to query from a database and group together changes that will then be written back to the store as a unit. And
DbSetrepresents a Repository pattern.
LINQ to SQL
ObjectContextclass in the
Use Session-per-Request is preferred than Session-per-Operation.
It means that all database operations should be executed in the one session.
Patterns in Practice - The Unit Of Work Pattern And Persistence Ignorance
Documentation about ORMs