Comprender los servicios de Symfony2

Question

Soy bastante nuevo en Symfony 2 y me estoy moviendo a temas avanzados como services. ¿Cuándo debería un objeto ser un servicio?

Por ejemplo, supongamos que tiene un objeto fachada para realizar una llamada a un servicio REST. Esta clase necesita un nombre de usuario y contraseña. ¿Sería correcto modelar esa clase como un servicio global? ¿Incluso si se usa solo en una parte del proyecto completo?

# app/config/config.yml 
parameters: 
    my_proxy.username: username 
    my_proxy.password: password 

services: 
    my_proxy: 
     class:  Acme\TestBundle\MyProxy 
     arguments: [%my_proxy.username%, %my_proxy.password%] 

Answer 1

Definición tomada de la Symfony2 glossary:

Un servicio es un término genérico para cualquier objeto PHP que realiza una tarea específica. Un servicio generalmente se usa "globalmente", como un objeto de conexión de base de datos o un objeto que entrega mensajes de correo electrónico. En Symfony2, los servicios a menudo se configuran y recuperan del contenedor de servicios. Se dice que una aplicación que tiene muchos servicios desacoplados sigue una arquitectura orientada a servicios.

Creo que su ejemplo es un candidato perfecto para un servicio.

No desea copiar el código de construcción a todos los lugares que necesita su cliente API. Es mejor delegar esta tarea al contenedor de inyección de dependencia.

De esta manera es más fácil de mantener (ya que la construcción se realiza en un solo lugar y es configurable).

También es más flexible ya que puede cambiar fácilmente la clase de cliente API sin afectar el código que lo utiliza (siempre que implemente la misma interfaz).

No creo que haya una regla de oro. Pero básicamente todas las clases que implementan una tarea son buenos candidatos para un servicio. Las entidades, por otro lado, no lo son, ya que a menudo solo son titulares de datos.

Siempre recomiendo la serie de artículos de Fabien sobre el tema: http://fabien.potencier.org/article/11/what-is-dependency-injection

Answer 2

Sí, porque esto le ahorrará la parte de configuración. No va a buscar el nombre de usuario y la contraseña, y se los dará al constructor cada vez que necesite esta clase.