Repository Pattern

The Repository Pattern is a common construct to avoid duplication of data access logic throughout our application. This includes direct access to a database, ORM, WCF dataservices, xml files and so on. The sole purpose of the repository is to hide the nitty gritty details of accessing the data. We can easily query the repository for data objects, without having to know how to provide things like a connection string. The repository behaves like a freely available in-memory data collection to which we can add, delete and update objects.
The Repository pattern adds a separation layer between the data and domain layers of an application. It also makes the data access parts of an application better testable.

Use the Repository pattern to achieve one or more of the following objectives:

• You want to maximize the amount of code that can be tested with automation and to isolate the data layer to support unit testing.
• You access the data source from many locations and want to apply centrally managed, consistent access rules and logic.
• You want to implement and centralize a caching strategy for the data source.
• You want to improve the code's maintainability and readability by separating business logic from data or service access logic.
• You want to use business entities that are strongly typed so that you can identify problems at compile time instead of at run time.
• You want to associate a behavior with the related data. For example, you want to calculate fields or enforce complex relationships or business rules between the data elements within an entity.
• You want to apply a domain model to simplify complex business logic.

Use a repository to separate the logic that retrieves the data and maps it to the entity model from the business logic that acts on the model. The business logic should be agnostic to the type of data that comprises the data source layer. For example, the data source layer can be a database, a SharePoint list, or a Web service.
The repository mediates between the data source layer and the business layers of the application. It queries the data source for the data, maps the data from the data source to a business entity, and persists changes in the business entity to the data source. A repository separates the business logic from the interactions with the underlying data source or Web service. The separation between the data and business tiers has three benefits:

• It centralizes the data logic or Web service access logic.
• It provides a substitution point for the unit tests.
• It provides a flexible architecture that can be adapted as the overall design of the application evolves.

Repositories are bridges between data and operations that are in different domains. A common case is mapping from a domain where data is weakly typed, such as a database or SharePoint list, into a domain where objects are strongly typed, such as a domain entity model.

Repositories often use the Data Mapper pattern to translate between representations.