Christian Peters

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