Patrón Repository en JavaScript

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
function showDiscount(db, customer) {
  const { count } = db.prepare("SELECT COUNT(*) AS count FROM orders WHERE customer = ?").get(customer);
  const text = count > 3 ? "10 % de descuento" : "sin descuento";
  console.log(`${customer}: ${text}`);
}

// La caja
function checkout(db, customer, total) {
  const rows = db.prepare("SELECT id FROM orders WHERE customer = ?").all(customer);
  return rows.length >= 3 ? total * 0.9 : total;
}

const db = new DatabaseSync(":memory:");
setup(db);
showDiscount(db, "María");
console.log(`María paga ${checkout(db, "María", 50).toFixed(2)} €`);
db.close();

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.

En JavaScript la interfaz es más un acuerdo que un tipo: el servicio aceptará cualquier objeto que tenga findByCustomer. JavaScript no tiene interface, así que el acuerdo es un comentario encima de las clases. 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. En JavaScript el pedido es un objeto simple { id, customer, total }, y el contrato es un comentario.

// Todo repositorio de pedidos tiene estos tres métodos:
// findById(id), findByCustomer(customer), save(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 {
  #orders = new Map();

  findById(id) {
    return this.#orders.get(id) ?? null;
  }

  findByCustomer(customer) {
    return [...this.#orders.values()].filter((order) => order.customer === customer);
  }

  save(order) {
    this.#orders.set(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:

function fill(orders) {
  orders.save({ id: 1, customer: "María", total: 80 });
  orders.save({ id: 2, customer: "Mateo", total: 25.5 });
  orders.save({ id: 3, customer: "María", total: 40 });
  orders.save({ id: 4, customer: "María", total: 12.9 });
}

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 {
  constructor(orders) {
    this.orders = orders;
  }

  discountFor(customer) {
    return this.orders.findByCustomer(customer).length >= 3 ? 10 : 0;
  }
}

class OrderController {
  constructor(loyalty) {
    this.loyalty = loyalty;
  }

  show(customer) {
    const discount = this.loyalty.discountFor(customer);
    const text = discount > 0 ? `${discount} % de descuento` : "sin descuento";
    console.log(`${customer}: ${text}`);
  }
}

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

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

const db = new DatabaseSync(":memory:");
const database = new SqliteOrderRepository(db);
fill(database);
new OrderController(new LoyaltyService(database)).show("María");
db.close();

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

class LoyaltyService {
  constructor(orders) {
    this.orders = orders;
  }

  discountFor(customer) {
    return this.orders.findByCustomer(customer).length >= 3 ? 10 : 0;
  }
}

class OrderController {
  constructor(loyalty) {
    this.loyalty = loyalty;
  }

  show(customer) {
    const discount = this.loyalty.discountFor(customer);
    const text = discount > 0 ? `${discount} % de descuento` : "sin descuento";
    console.log(`${customer}: ${text}`);
  }
}

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

const db = new DatabaseSync(":memory:");
const database = new SqliteOrderRepository(db);
fill(database);
new OrderController(new LoyaltyService(database)).show("María");
db.close();

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 el repositorio. 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. Tiene los mismos métodos, 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 (?), nunca texto pegado dentro del SQL. Por qué esto importa está en la lección Inyección SQL y parámetros.

class SqliteOrderRepository {
  constructor(db) {
    this.db = db;
    db.exec("CREATE TABLE IF NOT EXISTS orders (id INTEGER PRIMARY KEY, customer TEXT NOT NULL, total REAL NOT NULL)");
  }

  findById(id) {
    return this.db.prepare("SELECT id, customer, total FROM orders WHERE id = ?").get(id) ?? null;
  }

  findByCustomer(customer) {
    return this.db.prepare("SELECT id, customer, total FROM orders WHERE customer = ? ORDER BY id").all(customer);
  }

  save(order) {
    this.db
      .prepare("INSERT INTO orders (id, customer, total) VALUES (?, ?, ?) ON CONFLICT (id) DO UPDATE SET customer = excluded.customer, total = excluded.total")
      .run(order.id, order.customer, order.total);
  }
}

node:sqlite devuelve las filas como objetos con los nombres de las columnas, así que un pedido de la base de datos se ve igual que uno de la memoria.

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.

const orders = new InMemoryOrderRepository();
const loyalty = new LoyaltyService(orders);
orders.save({ id: 1, customer: "María", total: 80 });
orders.save({ id: 2, customer: "María", total: 40 });
console.log(`2 pedidos: ${loyalty.discountFor("María")}%`);
orders.save({ id: 3, customer: "María", total: 12.9 });
console.log(`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?

const orders = new InMemoryOrderRepository();
orders.save({ id: 1, customer: "María", total: 80 });
orders.save({ id: 1, customer: "María", total: 50 });
console.log(orders.findByCustomer("María").length);
console.log(`${orders.findById(1).total.toFixed(2)} €`);

Respuesta

1 / 80.00 €

1 / 50.00 €

2 / 50.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 {
  #byCustomer = new Map();

  findById(id) {
    for (const orders of this.#byCustomer.values()) {
      const found = orders.find((order) => order.id === id);
      if (found) {
        return found;
      }
    }
    return null;
  }

  findByCustomer(customer) {
    return this.#byCustomer.get(customer) ?? [];
  }

  save(order) {
    for (const [customer, orders] of this.#byCustomer) {
      this.#byCustomer.set(customer, orders.filter((o) => o.id !== order.id));
    }
    if (!this.#byCustomer.has(order.customer)) {
      this.#byCustomer.set(order.customer, []);
    }
    this.#byCustomer.get(order.customer).push(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 {
  constructor(orders) {
    this.orders = orders;
  }

  discountFor(customer) {
    return this.orders.findByCustomer(customer).length >= 3 ? 10 : 0;
  }

  discountIfBuys(customer, cart) {
    const orders = this.orders.findByCustomer(customer);
    orders.push(cart);
    return orders.length >= 3 ? 10 : 0;
  }
}

const orders = new FastOrderRepository();
fill(orders);
const loyalty = new LoyaltyService(orders);
console.log(`Si Mateo compra una más: ${loyalty.discountIfBuys("Mateo", { id: 5, customer: "Mateo", total: 30 })}%`);
console.log(`Pedidos de Mateo: ${orders.findByCustomer("Mateo").length}`);

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 (el modelo de Prisma). 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