The Repository Pattern

In this lesson, you will learn how the Repository Pattern acts as a mediator between your domain logic and the persistence layer to decouple how your application uses data from how it is actually stored.

Bridging the Gap

Up until now, we have discussed how to manage connections, handle pooling, and optimize query execution. However, if your business logic—the code that calculates discounts, processes orders, or validates users—is tightly coupled to SQL queries or specific ORM methods, your system becomes fragile. If you decide to switch from a relational database to a document store, or even simply refactor your schema, you shouldn't have to rewrite your entire business logic layer.

The Repository Pattern solves this by creating an abstraction layer that mimics a collection of domain objects in memory. Instead of the business layer calling SELECT * FROM users WHERE active = 1, it interacts with an interface, like UserRepository.getActiveUsers().

Implementation Illustration

By defining an interface, the business layer remains ignorant of whether the data comes from a SQL database, a cache, or a web service.

// The Interface: The business logic only knows this exists
public interface IUserRepository {
    User GetById(int id);
    void Save(User user);
}

// The Implementation: The "Repository" hides the SQL details
public class SqlUserRepository : IUserRepository {
    public User GetById(int id) {
        // Here, the repository encapsulates your connection pooling, 
        // SQL execution, and hydration logic.
        return _connection.Query<User>("SELECT * FROM Users WHERE Id = @id", new { id });
    }
}

By hiding the persistence strategy, you gain several architectural benefits. First, your unit tests can inject a "Mock" repository that holds data in a simple List<T> instead of requiring a real database connection. Second, you centralize data access logic, making it easier to implement patterns like caching or auditing without cluttering your services. You are effectively shifting from "sending queries" to "managing collections," which keeps your database concerns strictly contained within the repository boundary.

Key Takeaway: The Repository Pattern decouples your business domain from your data access infrastructure, allowing you to change storage strategies without forcing a rewrite of your core application logic.