¿Cuál es la vida útil del contenedor de servicio?

Estoy tratando de entender el marco de Symfony2.

Procedente de un fondo de Java / Spring, me di cuenta de que Scope en Symfony2 es diferente de Scope en Spring. Además, con Symfony3, Scope está en desuso , pero podemos especificar si un servicio se comparte o no.

¿Qué significa esto?

¿El objeto de servicio será preservado por el contenedor de servicio hasta su vida útil? ¿Eso significa que puedo usar las variables miembro para mantener información con estado entre las solicitudes? (No estoy seguro si eso es realmente posible porque aparentemente eso no sucede).

Por lo tanto, probablemente no abarque todas las solicitudes. ¿La vida útil del contenedor de servicio es igual a la solicitud? Porque me doy cuenta si tengo una dependencia utilizada por dos consumidores, si configuro shared: false , cada consumidor obtiene un “estado” diferente de la dependencia. Pero están esencialmente en la misma solicitud.

¿Qué significa especificar shared: false realmente significa? O qué shared: true significado?

Lifetime for service es solicitud única.

El servicio compartido significa que se devolverá la misma instancia cada vez que se acceda al servicio. Si establece shared: false , se creará una nueva instancia de servicio cada vez que solicite el servicio.

También mencionó a 2 consumidores. Creo que ejecuta a sus consumidores como procesos separados, por lo que estas son solicitudes diferentes y diferentes ámbitos.

Aunque Mantas tiene razón en la mayoría de los casos, afirmar que la vida útil es una sola solicitud podría ser engañosa en algunos casos extremos.

Básicamente, el contenedor de servicio vive mientras el Kernel viva. El contenedor de servicio se inicializa durante Kernel::boot() que se llama la primera vez que el Kernel maneja una solicitud. (Consulte, por ejemplo, su controlador frontal, app.php). El contenedor se descarta en Kernel::shutdown() o cuando finaliza el proceso PHP.

Por lo tanto, cuando deja que su Kernel maneje múltiples solicitudes, o cada vez que hace subreques durante la vida útil de su Kernel, el contenedor de servicios aún existe y se conserva cualquier estado en sus servicios.

Tomemos como ejemplo los siguientes dos fragmentos de código:

 $kernel = new AppKernel('prod', false); $kernel->loadClassCache(); $responseOne = $kernel->handle($requestOne); // Container initialised $responseOne->send(); $kernel->terminate($requestOne, $responseOne); $responseTwo = $kernel->handle($requestTwo); // Container still exists $responseTwo->send(); $kernel->terminate($requestTwo, $responseTwo); $kernel->shutdown(); // Container destructed 

Y

 $kernel = new AppKernel('prod', false); $kernel->loadClassCache(); $responseOne = $kernel->handle($requestOne); // Container initialised $responseOne->send(); $kernel->terminate($requestOne, $responseOne); $kernel->shutdown(); // Container destructed $responseTwo = $kernel->handle($requestTwo); // New Container initialised $responseTwo->send(); $kernel->terminate($requestTwo, $responseTwo); // PHP exits, container destructed 

En la mayoría de los casos, su proceso PHP tendrá la duración de una solicitud a su servidor web. Sin embargo, hay situaciones en las que puede aprovechar la capacidad de mantener el kernel, incluido el contenedor de servicio, vivo entre las solicitudes. Por ejemplo, está el proyecto php-pm, que básicamente mantiene su kernel vivo y activa las solicitudes.

Esto permitirá una gran mejora en el rendimiento (no hay gastos generales para construir un contenedor e inicializar paquetes una y otra vez para cada solicitud). Por otro lado, sus servicios se compartirán para múltiples solicitudes y, probablemente, para múltiples usuarios, lo que significa que el ahorro de estado en sus servicios puede suponer un gran riesgo de seguridad.

Por lo tanto, siempre separe sus clases de datos de sus servicios y no almacene datos en sus servicios. Symfony es un buen ejemplo, separa datos usando las clases de Solicitud y Respuesta.