Christian Peters

The Unit of Work pattern defines an approach to create logical transactions within a system that might otherwise not be transaction based. It commonly is used in conjunction with the Repository Design Pattern. I have previously used the Unit of Work pattern only in relation to database operations, but it could be used for file access, other sources, or multiple types together; the key is that all work gets completed as if it were one action. Reasons you would want to use the Unit or Work pattern Allows for smaller components that do not need coordination logic More efficient by reducing duplicated or unneeded work, only the final result is stored Ensures working with up-to-date entities If one piece fails, all fail, guaranteeing data in a good state How do you implement Unit of Work? In my opinion, one of the best ways to use the Unit of Work pattern would be for your Unit of Work to be created as soon as a request comes into your system and to be completed right before yo

Design Patterns are an approach to solve problems when creating a piece of software. They are useful as a best practice template when solving a problem. They also give you and your teammates a common understanding when discussing how to solve a given problem. That common understanding only happens if everyone on your team knows the patterns.  I am using this space to collect a series of posts that will dig into my understanding of common Design Patterns. Repository Pattern Unit of Work  

The Repository Pattern is a pattern that defines how to access data in a reusable, isolated fashion. The core concept is to isolate the logic required to call a database, file, or other data source. It can be reused without other layers of the software needing to know the details of how to get that data. An example would be the connection string for a database should be used in 1 location, within a repository, rather than every class that needed data needing a connection string. The repository is used by calling classes like a collection of data. If I have an employee repository, classes that need an employee can query the employee repository as if all employees were already in an in-memory collection. var employee = _employeeRepository.FindById(1); I view the repository as the bottom layer of code. Isolating data access from the rest of your code has multiple benefits. You can easily write tests by faking or mocking your repository. You do not actually connect to your data s