Unity of Work Repository Pattern

Repository Pattern separates the data access logic and maps it to the entities in the business logic. It works with the domain entities and performs data access logic. In the Repository pattern, the domain entities, the data access logic and the business logic talk to each other using interfaces. It hides the details of data access from the business logic. In other words, business logic can access the data object without having knowledge of the underlying data access architecture. For example, in the Repository pattern, business logic is not aware whether the application is using LINQ to SQL or ADO.NET Entity Model ORM. In the future, underlying data sources or architecture can be changed without affecting the business logic.

There are various advantages of the Repository Pattern including:

• Business logic can be tested without need for an external source
• Database access logic can be tested separately
• No duplication of code
• Caching strategy for the datasource can be centralized
• Domain driven development is easier
• Centralizing the data access logic, so code maintainability is easier

The Unit of Work Pattern is used to group one or more operations (usually database CRUD operations) into a single transaction or “unit of work” so that all operations either pass or fail as one. In simple word we can say that for a specific user action, say booking on a website, all the transactions like insert/update/delete and so on are done in one single transaction, rather than doing multiple database transactions. This means, one unit of work here involves insert/update/delete operations, all in one single transaction so that all operations either pass or fail as one

Please refer this link for better understanding through the code implementation;
https://dotnettutorials.net/lesson/unit-of-work-csharp-mvc/