Patrón Repository en C#

Problema

Consultas repartidas entre la página y la caja

La tienda da un 10 % de descuento a un cliente con tres pedidos o más. La página del cliente muestra si hay descuento, y la caja lo aplica al pagar. Cada una escribe su propia consulta a la base de datos y su propia regla:

using var conn = new SqliteConnection("Data Source=:memory:");
conn.Open();
Setup(conn);
ShowDiscount(conn, "María");
Console.WriteLine($"María paga {Checkout(conn, "María", 50.00m):F2} €");

// La página del cliente
static void ShowDiscount(SqliteConnection conn, string customer)
{
    var cmd = conn.CreateCommand();
    cmd.CommandText = "SELECT COUNT(*) FROM orders WHERE customer = $customer";
    cmd.Parameters.AddWithValue("$customer", customer);
    var count = Convert.ToInt32(cmd.ExecuteScalar());
    var text = count > 3 ? "10 % de descuento" : "sin descuento";
    Console.WriteLine($"{customer}: {text}");
}

// La caja
static decimal Checkout(SqliteConnection conn, string customer, decimal total)
{
    var cmd = conn.CreateCommand();
    cmd.CommandText = "SELECT id FROM orders WHERE customer = $customer";
    cmd.Parameters.AddWithValue("$customer", customer);
    using var reader = cmd.ExecuteReader();
    var count = 0;
    while (reader.Read())
    {
        count++;
    }
    return count >= 3 ? total * 0.9m : total;
}

María: sin descuento
María paga 45.00 €

María tiene tres pedidos. Su página le dice «sin descuento», porque allí la regla es count > 3. La caja le da el descuento, porque allí es count >= 3. Dos sitios, dos versiones de una regla, y nadie lo nota hasta que un cliente se queja.

Hay un segundo problema. La regla está pegada a la consulta. Para comprobar si >= 3 es correcto, necesitas una base de datos con una tabla y filas. La tabla orders y sus filas las llena la función Setup, como en las lecciones sobre la base de datos en el programa. Aquí está oculta para que no estorbe.

La idea

Repository: los datos detrás de una interfaz

Las consultas van a un solo lugar: un repositorio. Tiene unos pocos métodos con nombres en el lenguaje de la tienda, no de la base de datos: FindById, FindByCustomer, Save. Quien necesita pedidos los llama y no sabe si detrás hay SQL, un archivo o un diccionario en memoria.

Este es el patrón Repository. Alrededor, el código se ordena en capas, y cada capa habla solo con la capa de debajo:

el controlador (la página, la caja) recibe la petición y muestra la respuesta;
el servicio tiene la regla: «tres pedidos o más dan un 10 %»;
el repositorio da y guarda datos. No hay reglas en él;
los datos: memoria, SQLite u otra base de datos.

El servicio recibe el repositorio desde fuera, en su constructor. Es la inyección de dependencias (Dependency Injection) de la lección Singleton e inyección de dependencias. Por eso debajo puede ir cualquier repositorio con los mismos métodos.

Míralo

El contrato y el repositorio en memoria

El pedido y el contrato del repositorio: tres métodos, y ni una línea de SQL.

record Order(int Id, string Customer, decimal Total);

interface IOrderRepository
{
    Order? FindById(int id);
    List<Order> FindByCustomer(string customer);
    void Save(Order order);
}

El primer repositorio guarda los pedidos en memoria, en un diccionario del número al pedido. Save con el mismo número reemplaza el pedido viejo.

class InMemoryOrderRepository : IOrderRepository
{
    private readonly Dictionary<int, Order> orders = new();

    public Order? FindById(int id) => orders.GetValueOrDefault(id);

    public List<Order> FindByCustomer(string customer)
    {
        var result = new List<Order>();
        foreach (var order in orders.Values)
        {
            if (order.Customer == customer)
            {
                result.Add(order);
            }
        }
        return result;
    }

    public void Save(Order order) => orders[order.Id] = order;
}

Una función llena cualquier repositorio con los pedidos de la tienda. Solo conoce el contrato, así que funciona con la memoria y con la base de datos:

static void Fill(IOrderRepository orders)
{
    orders.Save(new Order(1, "María", 80.00m));
    orders.Save(new Order(2, "Mateo", 25.50m));
    orders.Save(new Order(3, "María", 40.00m));
    orders.Save(new Order(4, "María", 12.90m));
}

Míralo

El servicio no sabe de dónde vienen los datos

La regla está en el servicio, y el controlador solo muestra la respuesta. Ninguno de los dos escribe SQL:

class LoyaltyService
{
    private readonly IOrderRepository orders;

    public LoyaltyService(IOrderRepository orders)
    {
        this.orders = orders;
    }

    public int DiscountFor(string customer) => orders.FindByCustomer(customer).Count >= 3 ? 10 : 0;
}

class OrderController
{
    private readonly LoyaltyService loyalty;

    public OrderController(LoyaltyService loyalty)
    {
        this.loyalty = loyalty;
    }

    public void Show(string customer)
    {
        var discount = loyalty.DiscountFor(customer);
        var text = discount > 0 ? $"{discount} % de descuento" : "sin descuento";
        Console.WriteLine($"{customer}: {text}");
    }
}

El mismo servicio y el mismo controlador, primero sobre la memoria, luego sobre SQLite:

IOrderRepository memory = new InMemoryOrderRepository();
Fill(memory);
new OrderController(new LoyaltyService(memory)).Show("María");

using var conn = new SqliteConnection("Data Source=:memory:");
conn.Open();
IOrderRepository database = new SqliteOrderRepository(conn);
Fill(database);
new OrderController(new LoyaltyService(database)).Show("María");

María: 10 % de descuento
María: 10 % de descuento

class LoyaltyService
{
    private readonly IOrderRepository orders;

    public LoyaltyService(IOrderRepository orders)
    {
        this.orders = orders;
    }

    public int DiscountFor(string customer) => orders.FindByCustomer(customer).Count >= 3 ? 10 : 0;
}

class OrderController
{
    private readonly LoyaltyService loyalty;

    public OrderController(LoyaltyService loyalty)
    {
        this.loyalty = loyalty;
    }

    public void Show(string customer)
    {
        var discount = loyalty.DiscountFor(customer);
        var text = discount > 0 ? $"{discount} % de descuento" : "sin descuento";
        Console.WriteLine($"{customer}: {text}");
    }
}

IOrderRepository memory = new InMemoryOrderRepository();
Fill(memory);
new OrderController(new LoyaltyService(memory)).Show("María");

using var conn = new SqliteConnection("Data Source=:memory:");
conn.Open();
IOrderRepository database = new SqliteOrderRepository(conn);
Fill(database);
new OrderController(new LoyaltyService(database)).Show("María");

Paso a paso, en palabras

Un repositorio en memoria, lleno de pedidos. El servicio lo recibe sin saber qué es.
El controlador recibe la petición para María. No le pregunta a la base de datos: llama al servicio.
El servicio necesita los pedidos del cliente y se los pide al repositorio.
FindByCustomer sobre IOrderRepository. Responde el repositorio en memoria: recorre su diccionario.
Tres pedidos de María suben. La regla está aquí y solo aquí: 3 ≥ 3, así que 10 %.
El controlador solo muestra la respuesta: «María: 10 % de descuento».
El cambio: SQLite ocupa el lugar de la memoria. Es el mismo IOrderRepository, así que el servicio y el controlador no se tocan.
La misma llamada. Solo es distinto el objeto que hay debajo del servicio.
FindByCustomer ahora envía SELECT … WHERE customer = ? a la tabla orders.
Otra vez tres filas, otra vez 10 %. El servicio no se enteró de que la fuente es otra.
La misma línea, esta vez desde una base de datos.
Controlador → servicio → repositorio → datos. Solo cambió la capa de más abajo, y la regla se quedó en un solo lugar.

Solo cambió la capa de más abajo. El servicio y el controlador son las mismas clases, sin una sola línea cambiada, y María ahora recibe el descuento tanto en la página como en la caja, porque hay una sola regla.

Míralo

La base de datos real detrás de la misma interfaz

Aquí está el repositorio en SQLite. Cada método es una consulta con parámetros ($customer), nunca texto pegado dentro del SQL. Por qué esto importa está en la lección Inyección SQL y parámetros.

class SqliteOrderRepository : IOrderRepository
{
    private readonly SqliteConnection conn;

    public SqliteOrderRepository(SqliteConnection conn)
    {
        this.conn = conn;
        var cmd = conn.CreateCommand();
        cmd.CommandText = "CREATE TABLE IF NOT EXISTS orders (id INTEGER PRIMARY KEY, customer TEXT NOT NULL, total REAL NOT NULL)";
        cmd.ExecuteNonQuery();
    }

    public Order? FindById(int id)
    {
        var cmd = conn.CreateCommand();
        cmd.CommandText = "SELECT id, customer, total FROM orders WHERE id = $id";
        cmd.Parameters.AddWithValue("$id", id);
        using var reader = cmd.ExecuteReader();
        return reader.Read() ? Read(reader) : null;
    }

    public List<Order> FindByCustomer(string customer)
    {
        var cmd = conn.CreateCommand();
        cmd.CommandText = "SELECT id, customer, total FROM orders WHERE customer = $customer ORDER BY id";
        cmd.Parameters.AddWithValue("$customer", customer);
        using var reader = cmd.ExecuteReader();
        var result = new List<Order>();
        while (reader.Read())
        {
            result.Add(Read(reader));
        }
        return result;
    }

    public void Save(Order order)
    {
        var cmd = conn.CreateCommand();
        cmd.CommandText = "INSERT INTO orders (id, customer, total) VALUES ($id, $customer, $total) ON CONFLICT (id) DO UPDATE SET customer = excluded.customer, total = excluded.total";
        cmd.Parameters.AddWithValue("$id", order.Id);
        cmd.Parameters.AddWithValue("$customer", order.Customer);
        cmd.Parameters.AddWithValue("$total", order.Total);
        cmd.ExecuteNonQuery();
    }

    private static Order Read(SqliteDataReader r) => new(r.GetInt32(0), r.GetString(1), r.GetDecimal(2));
}

IOrderRepository no sabe nada de SqliteConnection. Solo este repositorio la conoce, y el servicio ve la interfaz.

Aquí vive el SQL de los pedidos. Aquí puedes arreglar una consulta lenta, añadir un índice o cambiar SQLite por PostgreSQL, y el servicio no se entera. Si el repositorio se convierte en un ORM, cuidado con una consulta por fila: la lección ORM y el problema N+1 muestra cómo se ve.

Míralo

La regla sin base de datos

Como el servicio acepta cualquier repositorio, la regla se comprueba con el repositorio en memoria: sin archivo, sin servidor, en milisegundos.

var orders = new InMemoryOrderRepository();
var loyalty = new LoyaltyService(orders);
orders.Save(new Order(1, "María", 80.00m));
orders.Save(new Order(2, "María", 40.00m));
Console.WriteLine($"2 pedidos: {loyalty.DiscountFor("María")}%");
orders.Save(new Order(3, "María", 12.90m));
Console.WriteLine($"3 pedidos: {loyalty.DiscountFor("María")}%");

2 pedidos: 0%
3 pedidos: 10%

Dos pedidos no bastan, el tercero da un 10 %. Es justo el límite en el que la página y la caja no estaban de acuerdo. Así se ve también una prueba de la regla: llenas el repositorio en memoria y compruebas lo que dice el servicio.

Pruébalo

¿Qué saldrá?

El pedido número 1 se guarda dos veces, con un total distinto. ¿Qué imprime el programa?

IOrderRepository orders = new InMemoryOrderRepository();
orders.Save(new Order(1, "María", 80.00m));
orders.Save(new Order(1, "María", 50.00m));
Console.WriteLine(orders.FindByCustomer("María").Count);
Console.WriteLine($"{orders.FindById(1)!.Total:F2} €");

Respuesta

1 / 50.00 €

2 / 50.00 €

1 / 80.00 €

2 / 80.00 €

Pruébalo

Encuentra el error

Alguien decide que la búsqueda por cliente es lenta y escribe un repositorio que guarda los pedidos ya por cliente:

class FastOrderRepository : IOrderRepository
{
    private readonly Dictionary<string, List<Order>> byCustomer = new();

    public Order? FindById(int id)
    {
        foreach (var orders in byCustomer.Values)
        {
            foreach (var order in orders)
            {
                if (order.Id == id)
                {
                    return order;
                }
            }
        }
        return null;
    }

    public List<Order> FindByCustomer(string customer) => byCustomer.GetValueOrDefault(customer) ?? new List<Order>();

    public void Save(Order order)
    {
        foreach (var orders in byCustomer.Values)
        {
            orders.RemoveAll(o => o.Id == order.Id);
        }
        if (!byCustomer.ContainsKey(order.Customer))
        {
            byCustomer[order.Customer] = new List<Order>();
        }
        byCustomer[order.Customer].Add(order);
    }
}

En el servicio aparece un método nuevo: «¿habrá descuento si compra también este?». Luego la página pregunta cuántos pedidos tiene Mateo:

class LoyaltyService
{
    private readonly IOrderRepository orders;

    public LoyaltyService(IOrderRepository orders)
    {
        this.orders = orders;
    }

    public int DiscountFor(string customer) => orders.FindByCustomer(customer).Count >= 3 ? 10 : 0;

    public int DiscountIfBuys(string customer, Order cart)
    {
        var list = orders.FindByCustomer(customer);
        list.Add(cart);
        return list.Count >= 3 ? 10 : 0;
    }
}

IOrderRepository orders = new FastOrderRepository();
Fill(orders);
var loyalty = new LoyaltyService(orders);
Console.WriteLine($"Si Mateo compra una más: {loyalty.DiscountIfBuys("Mateo", new Order(5, "Mateo", 30.00m))}%");
Console.WriteLine($"Pedidos de Mateo: {orders.FindByCustomer("Mateo").Count}");

Si Mateo compra una más: 0%
Pedidos de Mateo: 2

Mateo tiene un pedido, y el repositorio dice dos. Nadie llamó a Save. ¿En qué línea del repositorio está el error?

Elige la línea con el error.

La idea

Cuándo no lo necesitas

Repository añade una interfaz y al menos una clase. No compensa cuando:

el programa es un script pequeño con una consulta. Las capas serán más largas que el trabajo mismo;
usas un ORM que ya da un repositorio (DbContext de Entity Framework). Tu propia interfaz que solo le reenvía línea por línea es un archivo más sin nada nuevo;
el repositorio gana un método por cada página: FindByCustomerAndStatusOrderByTotal y veinte más como ese. Entonces las consultas vuelven a estar repartidas, solo que con nombres más largos.

Compensa cuando las reglas deben comprobarse sin base de datos, cuando la fuente puede cambiar (una base de datos, un archivo, otro servicio) o cuando las mismas consultas se usan desde muchos sitios.

Ejercicio

Borrar del repositorio

Resuelve la tarea en tu editor.

Borrar. Añade Delete(id) al contrato y a los dos repositorios. En SQLite es DELETE FROM orders WHERE id = ?. Muestra el descuento de María, borra el pedido 4 y muéstralo otra vez, una vez con la memoria y otra con la base de datos.

María: 10 % de descuento
María: sin descuento
María: 10 % de descuento
María: sin descuento

Más tareas

Una regla por total. La tienda cambia la regla: 10 % a partir de 150 € gastados. ¿Qué clase tocas? Compruébalo con el repositorio en memoria, sin base de datos.
Un tercer repositorio. Escribe un repositorio que guarde los pedidos en un archivo, uno por línea. El servicio y el controlador deben quedar sin cambios.
Una copia al buscar. Arregla el repositorio de «Encuentra el error» y añade una comprobación: tras DiscountIfBuys Mateo sigue teniendo 1 pedido.

Test

Ponte a prueba

1. ¿Dónde vive la regla «3 pedidos o más dan un 10 % de descuento»?En el controlador, que muestra la respuestaEn el servicio, que recibe el repositorio desde fueraEn el repositorio, junto a la consulta

2. ¿Por qué la regla se puede comprobar sin una base de datos?No se puede: la regla siempre necesita la base de datos realPorque el servicio recibe el repositorio como interfaz, y basta con el repositorio en memoriaPorque SQLite es rápido

3. El repositorio devuelve la lista que guarda por dentro, y quien llama le añade algo. ¿Qué pasa?El pedido añadido aparece en el repositorio, sin que nadie llame a saveEl programa no compilaNada: la lista es una copia

4. El proyecto usa un ORM que ya da un repositorio para cada tabla. ¿Vale la pena poner encima una interfaz propia con los mismos métodos?No, los ORM prohíben las interfacesSí, siempre hay sitio para una capa másNormalmente no: una interfaz que solo reenvía al ORM añade código sin aportar nada

Repository

Cookies