Repository and Unit of Work Pattern
Repository and Unit of work pattern provides a clean way to access data using ORMs, keep all the data access logic in one central location and at the same time maintain the test-ability of the application.
- Improve the code's maintainability and readability by separating business logic from data or service access logic.
- To maximize the amount of code that can be tested with automation and to isolate the data.
What is the use of Unit of Work design pattern?
Unit of Work design pattern does two important things: first it maintains in-memory updates and second it sends these in-memory updates as one transaction to the database.
So to achieve the above goals it goes through two steps:
So to achieve the above goals it goes through two steps:
- It maintains lists of business objects in-memory which have been changed (inserted, updated, or deleted) during a transaction.
- Once the transaction is completed, all these updates are sent as one big unit of work to be persisted physically in a database in one go.
For example you can see in the below figure customer “Shiv” has two addresses, so for the below scenario the equation is:
3 Customer CRUD = 1 Logical unit of work
So in simple words, transactions for all of the three records should succeed or all of them should fail. It should be ATOMIC. In other words it’s very much possible that many CRUD operations will be equal to 1 unit of work.
Comments
Post a Comment