Veo a Symfony como dos grandes partes.
La primera parte es el sistema de rutas, controladores y respuestas.
Es muy sencillo y bueno...
¡ya eres un experto en ello!
La segunda mitad de Symfony son los numerosos objetos útiles que andan por ahí...
esperando a que los utilicemos
Por ejemplo, cuando renderizamos una plantilla, lo que estamos haciendo en realidad es aprovechar
un objeto Twig y pedirle que renderice una plantilla.
También hay un objeto registrador, un objeto caché, un objeto de conexión a la base de datos,
un objeto que ayuda a hacer peticiones a la API, ¡y muchos, muchos más!
Y cuando instalas un nuevo paquete, eso te da aún más objetos útiles.
La verdad es que todo lo que hace Symfony es...
en realidad lo hace uno de estos objetos útiles.
Diablos, ¡hay incluso un objeto router que se encarga
de encontrar la ruta adecuada para la página dada!
En el mundo de Symfony, y realmente en el mundo de la programación orientada a objetos en general,
estos "objetos que hacen trabajo" tienen un nombre especial: servicios.
Pero no dejes que esa palabra te confunda.
Cuando oigas servicio, piensa: ¡es un objeto que hace trabajo!
Como un objeto de plantilla que representa una plantilla
o un objeto de conexión a la base de datos que realiza consultas.
Y como los objetos de servicio hacen trabajo, son básicamente...
¡herramientas que te ayudan a hacer tu trabajo!
La segunda mitad de Symfony consiste en descubrir
qué servicios están disponibles y cómo utilizarlos.
Vamos a probar algo.
En nuestro controlador, quiero registrar un mensaje...
tal vez un mensaje de depuración.
Como registrar un mensaje es un trabajo, lo hace un servicio.
¿Nuestra aplicación ya tiene un servicio de registro?
Y si es así, ¿cómo lo conseguimos?
Para averiguarlo, ve a tu terminal y ejecuta otro comando bin/console:
php bin/console debug:autowiring Saluda a uno de los comandos más potentes de bin/console.
¡Me encanta esta cosa!
Esto lista todos los servicios que existen en nuestra aplicación.
Vale, en realidad no es la lista completa,
pero esto muestra los servicios que más probablemente necesitarás.
Y aunque nuestra aplicación es pequeña, ¡hay muchas cosas aquí!
Hay un servicio de sistema de archivos...
y aquí abajo un servicio de caché.
¡Incluso hay un servicio Twig!
¿Hay un servicio de registro?
Puedes buscar en esta lista...
o puedes volver a ejecutar este comando y buscar la palabra log: ¡Excelente!
Por ahora, ignora todo excepto la primera línea.
Esta línea nos dice que existe un servicio de registro
y que este objeto implementa una interfaz llamada Psr\Log\LoggerInterface.
Bien, ¿por qué nos ayuda saber eso?
Porque si quieres un servicio, lo pides utilizando la sugerencia de tipo que se muestra en este comando.
Se llama autoconexión.
Vamos a probarlo.
Dirígete a nuestro controlador y añade un segundo argumento.
En realidad, el orden de los argumentos no importa.
Lo que importa es que el nuevo argumento esté indicado con LoggerInterface.
Pulsaré el tabulador para autocompletarlo...
para que PhpStorm añada la declaración de uso en la parte superior.
En este caso, el argumento puede llamarse como sea, como $logger.
Cuando Symfony ve esta sugerencia de tipo, busca dentro de la lista debug:autowiring...
y como hay una coincidencia, nos pasará el servicio de registro.
Así que ahora conocemos dos tipos diferentes de argumentos que podemos tener en el controlador:
puedes tener un argumento cuyo nombre coincida con un comodín de la ruta
o un argumento cuyo tipo-indicación coincida con uno de los servicios de nuestra aplicación.
Bien, ahora que sabemos que Symfony nos pasará el objeto de servicio logger, ¡vamos a utilizarlo!
No sé, todavía, qué métodos puedo llamar en él, pero...
si decimos $logger->...
PhpStorm...
¡nos lo dice! ¡Ha sido fácil!
Voy a registrar algo en un nivel de prioridad info().
Digamos: Devolución de la respuesta de la API para la canción Y luego el $id.
En realidad, podemos hacer algo aún más genial con este servicio de registro.
Añade {song} al mensaje...
y añade un segundo argumento, que es un array
de información extra que quieres adjuntar al mensaje de registro.
Pasa song ajustado a $id.
En un momento, verás que el logger imprimirá el id real en lugar de {song}.
En cualquier caso, este controlador es para nuestra ruta de la API.
Así que vamos a actualizarlo.
Um... ¡bien! Así que no hay error, ¡eso es bueno!
¿Pero ha funcionado?
¿Dónde se registra el servicio de registro...
¿realmente se registra?
Averigüémoslo a continuación, aprendamos un truco para ver el perfilador incluso para las peticiones de la API
y luego aprovechemos nuestro segundo servicio directamente