Consultas de Datos Personalizadas en Controladores

Clase 16 de 22Curso de Bases de Datos en Symfony

Contenido del curso

Datos iniciales

Resumen

Cuando trabajamos con Doctrine y sus repositorios, los métodos comunes de consulta resuelven operaciones básicas con rapidez. Sin embargo, llega un momento en el que necesitamos resultados específicos y adaptados a nuestra lógica de negocio. Aquí es donde los métodos personalizados dentro de los repositorios se convierten en una herramienta fundamental para controlar exactamente qué datos obtenemos y cómo los organizamos.

¿Por qué los métodos comunes no siempre son suficientes?

Al utilizar métodos estándar como findAll o findBy, Doctrine genera consultas genéricas que pueden devolver más información de la necesaria. Por ejemplo, en una vista Home se pueden llegar a ejecutar cuarenta y un consultas [0:12] simplemente porque no se ha optimizado la forma en que se obtienen los datos. Si intentamos cambiar el nombre de un método común por uno inventado, el sistema arroja un error indicando que ese método no existe [0:30].

Esto confirma que los métodos predefinidos tienen nombres fijos. Para crear lógica propia, debemos trabajar directamente en el archivo del repositorio asociado a nuestra entidad.

¿Cómo crear un método personalizado en el repositorio?

El repositorio es la clase que Doctrine genera para cada entidad y sirve como puente entre el controlador y la base de datos. Dentro de esta clase podemos definir cualquier método con el nombre que necesitemos [1:05].

¿Qué es createQuery y cómo se utiliza?

El paso clave es invocar el método createQuery a través del Entity Manager [2:05]. Este método recibe como parámetro una cadena especial llamada DQL (Doctrine Query Language). La estructura básica luce así:

php $query = $this->getEntityManager()->createQuery( 'SELECT p FROM App\Entity\Product p ORDER BY p.id DESC' )->setMaxResults(12);

return $query->getResult();

  • p es el alias que asignamos a la entidad dentro de la consulta.
  • FROM App\Entity\Product p indica la entidad sobre la cual se ejecuta la consulta.
  • ORDER BY p.id DESC ordena los resultados de forma descendente por identificador.
  • setMaxResults(12) limita la respuesta a doce registros [2:30].

Al ejecutar getResult(), obtenemos un array donde cada elemento representa un producto con sus metadatos, comentarios y etiquetas [2:50].

¿Por qué especificar el tipo de retorno como array?

Es una buena práctica indicar el tipo de retorno en la firma del método. Si el sistema espera un string pero recibe un array, se genera un error de tipo [3:25]. Declarar : array al final de la definición del método garantiza coherencia y seguridad en el flujo de datos.

php public function findLatestProducts(): array { // ... }

¿Cuál es la diferencia entre DQL y SQL?

Este es uno de los conceptos más importantes al trabajar con Doctrine. DQL significa Doctrine Query Language y, aunque su sintaxis se parece mucho a SQL, opera a un nivel diferente [3:50].

  • DQL consulta entidades de Doctrine, es decir, clases PHP mapeadas a tablas. Trabaja con objetos y sus relaciones definidas en el código.
  • SQL opera directamente sobre el esquema de base de datos relacional, con tablas, columnas y joins explícitos [4:15].

Si exploramos el código fuente de Doctrine en la carpeta vendor/doctrine/orm, encontramos que la interfaz EntityManagerInterface define createQuery esperando específicamente un parámetro DQL [3:55]. Existe también un método separado que acepta SQL nativo, pero el enfoque recomendado para consultas sobre entidades es DQL por su integración con el ecosistema de Doctrine.

DQL resulta fácil de leer y es una opción válida cuando conocemos exactamente qué datos necesitamos de una entidad particular. La clave está en recordar que no estamos consultando tablas directamente, sino las clases que representan esas tablas en nuestra aplicación.

Practica creando tus propios métodos en el repositorio, experimenta con distintas condiciones en DQL y observa cómo se reducen las consultas innecesarias. En la próxima oportunidad se trabajará con QueryBuilder [4:45], una alternativa más flexible para construir consultas de forma programática. ¿Has notado diferencias de rendimiento al pasar de métodos comunes a consultas personalizadas? Comparte tu experiencia.