Spring Data: repositorios sin escribir el CRUD

Una interfaz vacía que Spring implementa sola: CRUD y búsquedas derivadas del nombre del método, sobre el mismo contenedor didáctico de Spring Boot.

15 aulas · 9 horas de práctica · en el navegador, sin instalar nada

Temario

  1. El problema que resuelve Spring Data — Cuánto código se repite, clase tras clase, para armar un CRUD a mano con un Map — y por qué ese código es tan mecánico que un framework puede escribirlo por vos.
  2. CrudRepository: los 5 métodos estándar — Una interfaz vacía que extiende CrudRepository<Entidad, Id> ya trae save, findById, findAll, deleteById y count implementados — inyectada por constructor o campo en un @Service, como cualquier otro bean del curso spring-boot.
  3. Query derivation I: findBy<Campo> — Spring "lee" el nombre de un método de la interfaz y arma la búsqueda a partir de él, sin que escribas ni una línea de implementación: findByNombre busca por igualdad sobre el campo nombre.
  4. Query derivation II: comparadores, Contains, True/False — Más allá de la igualdad: GreaterThan/LessThan para campos numéricos, Contains para buscar un texto dentro de un String, y True/False para filtrar un boolean sin recibir ningún parámetro.
  5. Query derivation III: And, y OrderBy — Combinar dos condiciones en un solo método con And, y ordenar el resultado con OrderBy<Campo>Asc/Desc — la última pieza de la gramática de query derivation que soporta este simulador.
  6. Taller — Catálogo de productos — Un repositorio con cinco búsquedas derivadas distintas (igualdad, comparador, OrderBy, Contains) y un Service que las expone, más un método propio que combina un findBy con una cuenta hecha a mano.
  7. Optional en la capa de servicio — findById nunca devuelve null: devuelve Optional<Entidad>, y qué hacer con eso —orElse para un default, orElseThrow para exigir que exista, map para transformar el valor solo si está presente— es una decisión de la capa de servicio, no del repositorio.
  8. IDs y su ciclo de vida — CrudRepository asume que la entidad YA tiene un id asignado antes de save(): en este simulador no hay autogeneración, así que asignarlo (con criterio, sin repetir valores) es responsabilidad de tu código, típicamente del Service.
  9. Entidad como record vs. clase plana — Un record es inmutable: "cambiar" un campo significa construir una instancia nueva y volver a guardarla. Una clase plana permite reasignar el campo directo. Ninguna es "la correcta" siempre: es un trade-off que ya viste en java-poo, aplicado ahora a una entidad de Spring Data.
  10. Capas: el Controller no usa el Repository directo — El Repository no sabe nada de reglas de negocio (ni debería): solo persiste. Si un Controller lo usa directo, se saltea cualquier validación que viva en el Service — el mismo problema de arquitectura en capas del curso spring-boot, ahora con un repositorio de por medio.
  11. Límites de query derivation, y @Query como referencia — Or, Between, In, IsNull, StartsWith/EndsWith, IgnoreCase, otros prefijos que no sean findBy, paginación: todo esto NO está soportado acá. El motor lo rechaza con un error real, no en silencio — y en Spring real, ahí es donde entra @Query con JPQL.
  12. Repositorios independientes, dos entidades relacionadas — Cliente y Pedido son entidades DISTINTAS, cada una con su propio repositorio y su propio mapa en memoria — no hay una relación real de base de datos entre ellas. Un Service que combina los dos es lo que en JPA real haría una relación @OneToMany, simplificada acá con un campo clienteId de tipo simple.
  13. Taller — Mesa de soporte — Dos repositorios independientes (Agente y Ticket) combinados en un Service: findByAgenteIdAndEstado para filtrar con And, Optional con orElseThrow para el agente que no existe, y una agregación (la prioridad máxima) hecha a mano sobre lo que Spring Data ya filtró.
  14. Cierre: una app completa con Spring Data — Todo el curso junto en un solo repositorio: CRUD, varias query derivations combinadas (And + comparador, OrderBy), Optional con orElseThrow, un id asignado a mano, y una regla de negocio en el Service — la misma receta que vas a repetir en proyectos reales.
  15. Taller — API de tareas — El cierre del curso como una API REST completa: Controller -> Service -> Repository, con las mismas reglas (validar antes de crear, Optional con orElse/if explícito, no completar dos veces) que ya escribiste en aulas anteriores, ahora expuestas por HTTP.

Es parte de