Repository

Código en:JavaC#PythonJavaScript

En resumen: Repository esconde la base de datos detrás de una interfaz con métodos como find y save, de modo que las reglas de negocio no saben nada de SQL y el almacenamiento puede cambiar sin que el servicio se entere.

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:

# La página del cliente
def show_discount(conn, customer):
    (count,) = conn.execute("SELECT COUNT(*) FROM orders WHERE customer = ?", (customer,)).fetchone()
    text = "10 % de descuento" if count > 3 else "sin descuento"
    print(f"{customer}: {text}")


# La caja
def checkout(conn, customer, total):
    rows = conn.execute("SELECT id FROM orders WHERE customer = ?", (customer,)).fetchall()
    return total * 0.9 if len(rows) >= 3 else total


conn = sqlite3.connect(":memory:")
setup(conn)
show_discount(conn, "María")
print(f"María paga {checkout(conn, 'María', 50.00):.2f} €")
conn.close()

Salida

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: find_by_id, find_by_customer, 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.

En Python la interfaz es más un acuerdo que un tipo: el servicio aceptará cualquier objeto que tenga find_by_customer. La clase base con ABC solo deja el acuerdo por escrito y te avisa pronto si falta un método. El patrón no desaparece: las capas y la regla en un solo lugar siguen igual.

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.

@dataclass(frozen=True)
class Order:
    id: int
    customer: str
    total: float


class OrderRepository(ABC):
    @abstractmethod
    def find_by_id(self, order_id): ...

    @abstractmethod
    def find_by_customer(self, customer): ...

    @abstractmethod
    def save(self, 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(OrderRepository):
    def __init__(self):
        self.orders = {}

    def find_by_id(self, order_id):
        return self.orders.get(order_id)

    def find_by_customer(self, customer):
        return [order for order in self.orders.values() if order.customer == customer]

    def save(self, order):
        self.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:

def fill(orders):
    orders.save(Order(1, "María", 80.00))
    orders.save(Order(2, "Mateo", 25.50))
    orders.save(Order(3, "María", 40.00))
    orders.save(Order(4, "María", 12.90))

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:
    def __init__(self, orders):
        self.orders = orders

    def discount_for(self, customer):
        return 10 if len(self.orders.find_by_customer(customer)) >= 3 else 0


class OrderController:
    def __init__(self, loyalty):
        self.loyalty = loyalty

    def show(self, customer):
        discount = self.loyalty.discount_for(customer)
        text = f"{discount} % de descuento" if discount > 0 else "sin descuento"
        print(f"{customer}: {text}")

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

memory = InMemoryOrderRepository()
fill(memory)
OrderController(LoyaltyService(memory)).show("María")

conn = sqlite3.connect(":memory:")
database = SqliteOrderRepository(conn)
fill(database)
OrderController(LoyaltyService(database)).show("María")
conn.close()

Salida

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

class LoyaltyService:
    def __init__(self, orders):
        self.orders = orders

    def discount_for(self, customer):
        return 10 if len(self.orders.find_by_customer(customer)) >= 3 else 0


class OrderController:
    def __init__(self, loyalty):
        self.loyalty = loyalty

    def show(self, customer):
        discount = self.loyalty.discount_for(customer)
        text = f"{discount} % de descuento" if discount > 0 else "sin descuento"
        print(f"{customer}: {text}")


memory = InMemoryOrderRepository()
fill(memory)
OrderController(LoyaltyService(memory)).show("María")

conn = sqlite3.connect(":memory:")
database = SqliteOrderRepository(conn)
fill(database)
OrderController(LoyaltyService(database)).show("María")
conn.close()

Paso a paso, en palabras

1. Un repositorio en memoria, lleno de pedidos. El servicio lo recibe sin saber qué es.
2. El controlador recibe la petición para María. No le pregunta a la base de datos: llama al servicio.
3. El servicio necesita los pedidos del cliente y se los pide al repositorio.
4. find_by_customer sobre OrderRepository. Responde el repositorio en memoria: recorre su diccionario.
5. Tres pedidos de María suben. La regla está aquí y solo aquí: 3 ≥ 3, así que 10 %.
6. El controlador solo muestra la respuesta: «María: 10 % de descuento».
7. El cambio: SQLite ocupa el lugar de la memoria. Es el mismo OrderRepository, así que el servicio y el controlador no se tocan.
8. La misma llamada. Solo es distinto el objeto que hay debajo del servicio.
9. find_by_customer ahora envía SELECT … WHERE customer = ? a la tabla orders.
10. Otra vez tres filas, otra vez 10 %. El servicio no se enteró de que la fuente es otra.
11. La misma línea, esta vez desde una base de datos.
12. 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 (?), nunca texto pegado dentro del SQL. Por qué esto importa está en la lección Inyección SQL y parámetros.

class SqliteOrderRepository(OrderRepository):
    def __init__(self, conn):
        self.conn = conn
        conn.execute("CREATE TABLE IF NOT EXISTS orders (id INTEGER PRIMARY KEY, customer TEXT NOT NULL, total REAL NOT NULL)")

    def find_by_id(self, order_id):
        row = self.conn.execute("SELECT id, customer, total FROM orders WHERE id = ?", (order_id,)).fetchone()
        return Order(*row) if row else None

    def find_by_customer(self, customer):
        rows = self.conn.execute("SELECT id, customer, total FROM orders WHERE customer = ? ORDER BY id", (customer,))
        return [Order(*row) for row in rows]

    def save(self, order):
        self.conn.execute(
            "INSERT INTO orders (id, customer, total) VALUES (?, ?, ?) ON CONFLICT (id) DO UPDATE SET customer = excluded.customer, total = excluded.total",
            (order.id, order.customer, order.total),
        )

Order(*row) crea un pedido a partir de la fila: las columnas están en el mismo orden que los campos de Order.

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.

orders = InMemoryOrderRepository()
loyalty = LoyaltyService(orders)
orders.save(Order(1, "María", 80.00))
orders.save(Order(2, "María", 40.00))
print(f"2 pedidos: {loyalty.discount_for('María')}%")
orders.save(Order(3, "María", 12.90))
print(f"3 pedidos: {loyalty.discount_for('María')}%")

Salida

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?

orders = InMemoryOrderRepository()
orders.save(Order(1, "María", 80.00))
orders.save(Order(1, "María", 50.00))
print(len(orders.find_by_customer("María")))
print(f"{orders.find_by_id(1).total:.2f} €")

Respuesta

2 / 50.00 €

1 / 80.00 €

1 / 50.00 €

2 / 80.00 €

Comprobar

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(OrderRepository):
    def __init__(self):
        self.by_customer = {}

    def find_by_id(self, order_id):
        for orders in self.by_customer.values():
            for order in orders:
                if order.id == order_id:
                    return order
        return None

    def find_by_customer(self, customer):
        return self.by_customer.get(customer, [])

    def save(self, order):
        for orders in self.by_customer.values():
            orders[:] = [o for o in orders if o.id != order.id]
        self.by_customer.setdefault(order.customer, []).append(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:
    def __init__(self, orders):
        self.orders = orders

    def discount_for(self, customer):
        return 10 if len(self.orders.find_by_customer(customer)) >= 3 else 0

    def discount_if_buys(self, customer, cart):
        orders = self.orders.find_by_customer(customer)
        orders.append(cart)
        return 10 if len(orders) >= 3 else 0

orders = FastOrderRepository()
fill(orders)
loyalty = LoyaltyService(orders)
print(f"Si Mateo compra una más: {loyalty.discount_if_buys('Mateo', Order(5, 'Mateo', 30.00))}%")
print(f"Pedidos de Mateo: {len(orders.find_by_customer('Mateo'))}")

Salida

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.

1class FastOrderRepository(OrderRepository):2 def __init__(self):3 self.by_customer = {}45 def find_by_id(self, order_id):6 for orders in self.by_customer.values():7 for order in orders:8 if order.id == order_id:9 return order10 return None1112 def find_by_customer(self, customer):13 return self.by_customer.get(customer, [])1415 def save(self, order):16 for orders in self.by_customer.values():17 orders[:] = [o for o in orders if o.id != order.id]18 self.by_customer.setdefault(order.customer, []).append(order)

Comprobar

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 (el modelo de Django). 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: find_by_customer_and_status_order_by_total 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(order_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.

Salida

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 discount_if_buys 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

Comprobar

Empezar la lección de nuevo

Lecciones relacionadas

• Se basa en: dataclass, match y patrones · Patrones de diseño · Strategy · Singleton e inyección de dependencias
• Continúa en: La tienda: qué patrón dónde · Capas · Arquitectura hexagonal y clean architecture · Monolito, monolito modular, servicios
• Ejercicios sobre el tema: Patrones de diseño