4.2. Configurando los servicios

La aplicación del blog necesita una utilidad que transforme los títulos de los artículos (ejemplo Hola Mundo) es un slug (ejemplo hola-mundo). Los slug son las cadenas de texto que se utilizan como parte de la URL de los artículos para evitar los caracteres problemáticos (espacios en blanco, acentos, etc.)

Así que se crea una nueva clase llamada Slugger dentro del directorio src/AppBundle/Utils/ y se define el siguiente método slugify():

// src/AppBundle/Utils/Slugger.php
namespace AppBundle\Utils;

class Slugger
{
    static function slugify($string)
    {
        return preg_replace(
            '/[^a-z0-9]/', '-', strtolower(trim(strip_tags($string)))
        );
    }
}

Para poder utilizar esta clase en tu aplicación, define un nuevo servicio de la siguiente manera:

# app/config/services.yml
services:
    # el nombre de los servicios debería ser muy corto
    slugger:
        class: AppBundle\Utils\Slugger

Normalmente los programadores Symfony utilizan nombres de servicios muy largos, compuestos por el nombre de la clase y su clase, bundle o namespace para evitar colisiones. Así que en este caso el servicio podría haberse llamado por ejemplo app.utils.slugger. Pero cuando se utilizan nombres cortos para los servicios, el código se simplifica y es más fácil de leer.

Ahora ya puedes utilizar el servicio slugger en cualquier controlador, como por ejemplo AdminController:

public function createAction(Request $request)
{
    // ...

    if ($form->isSubmitted() && $form->isValid()) {
        $slug = $this->get('slugger')->slugify($post->getTitle()));
        $post->setSlug($slug);

        // ...
    }
}

4.2.1. El formato de configuración YAML

En la sección anterior, se utilizó YAML para definir el servicio.

Sabemos que esta recomendación es muy controvertida. Según nuestra propia experiencia, el uso de YAML y XML está bastante repartido, con una ligera ventaja para YAML. En cualquier caso, como los dos formatos tienen el mismo rendimiento, al final la decisión de cuál utilizar es una cuestión de gusto personal.

La recomendación de utilizar YAML se debe a que los nuevos programadores Symfony pueden así definir los servicios más fácilmente y de manera muy concisa. Pero en tus aplicaciones puedes elegir el formato que prefieras.

4.2.2. No definas parámetros para las clases de los servicios

Probablemente te habrás dado cuenta de que antes no hemos creado un parámetro de configuración para definir la clase del servicio:

# app/config/services.yml

# creando un parámetro para definir la clase de un servicio
# NO lo hagas en tus aplicaciones
parameters:
    slugger.class: AppBundle\Utils\Slugger

services:
    slugger:
        class: "%slugger.class%"

Esta práctica es muy pesada y además, totalmente innecesaria para los servicios propios de tus aplicaciones.

Esta mala práctica tiene su origen de nuevo en los bundles de terceros. Si desarrollas un bundle para compartirlo públicamente, entonces probablemente sí que tienes que definir parámetros para las clases de tus servicios. Pero si estás definiendo servicios internos que sólo utilizará tu aplicación, entonces no hay necesidad de hacer que sus clases sean configurables.