I will talk about the Repository pattern mentioned as one of the "Patterns of Enterprise Application Architecture (PoEAA)" in well-known Martin Fowler's book. This is one of the widely used patterns in software industry. For you who already declared yourself as a software architect, this pattern is not something new. For you who haven't heard about this before, this posting will describe the basic structure and usage of this pattern.
I will use three different references in describing Repository pattern. I already mentioned the first one above. The second reference is the book from Eric Evans titled "Domain Driven Design: Tackling Complexity in the Hearth of Software (DDD)". And the third one is from Rob Conery in his Storefront video series. From these three sources, the DDD from Eric Evans gives the most descriptive and clear understanding about Repository pattern.
In PoEAA, Martin mentioned that a Repository mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers.
In DDD, Eric Evans mentioned that Repository represents all objects of a certain type as a conceptual set (usually emulated). It acts like a collection, except with more elaborate querying capability. Objects of the appropriate type are added and removed, and the machinery behind the Repository inserts them or deletes them from the database.
Clients request objects from the Repository using query methods that select objects based on criteria specified by the client, typically the value of certain attributes. The Repository retrieves the requested object, encapsulating the machinery of database queries and metadata mapping. Repositories can implement a variety of queries that select objects based on whatever criteria the client requires. They can also return summary information, such as a count of how many instances meet some criteria. They can even return summary calculations, such as the total across all matching objects of some numerical attribute.
Furthermore, Eric mentioned the advantages of using Repository:
- They present clients with a simple model for obtaining persistent objects and managing their life cycle.
- They decouple application and domain design from persistence technology, multiple database strategies, or even multiple data sources.
- They communicate design decisions about object access.
- They allow easy substitution of a dummy implementation, for use in testing (typically using an in-memory collection).
Rob Conery does not give any further definition about the Repository pattern. But he produced a nice diagram about the pattern in architectural context. Here is his Repository pattern diagram:
In this diagram Rob emphasizes on the use of Virtualized Interface as the contract between client (Application code) and the Repository (DataSet or Custom Persistence Format). This is related with his Repository implementation using IQueryable from LINQ. If we relate this diagram with the diagram from Eric, the model terms used here is an interface, not specific type or class. I will explain further about this approach in a separate posting since this can be categorized as platform specific implementation of Repository pattern.
As conclusion, Repository pattern can make client applications unaware of how data is retrieved and stored in the data store. All clients have to know is a repository that can be queried using any criteria that clients want. This pattern decouples data store implementation with application logics so that it can be freely replaced with other implementation if necessary.
