Bienvenidos en esta clase vamos a hablar sobre los distintos contexto o alcance de los componentes.
El Scoob que se le llama por defecto vimos que son del tipo singleton, es decir, vaban tener en el
contenedor de Spring una sola instancia de ese componente por defecto.
Y no solamente se aplica a factura que está anotado con component, sino también a los controladores.
Por ejemplo, si nos vamos a controllers factura controllers, un controlador que también es un componente
de Spring también en el contexto o scope singleton.
Vamos a tener una sola instancia de ese controlador para toda la aplicación y se va a utilizar en cada
request en cada petición de los distintos clientes que estén usando esta aplicación.
Ese por defecto igual se puede cambiar a un contexto, por ejemplo del request o de sesión.
Hay que tener cuidado y presente que cuando es singleton el por defecto, no podemos tener atributos
en el controlador que sea propio del usuario, ya que también podrían ser modificados por otros usuarios
por otras peticiones.
Entonces la idea es que todos estos objetos que inyectamos sean styles.
Es decir, sin estado que no mantenga estado, no mantenga valores en los atributos o información del
usuario.
Como sería una sesión, un carro de compra, por ejemplo.
Para eso utilizamos otro contexto que sería, por ejemplo del Rickert o como había mencionado, del
tipo sesión de sesión.
Pero bueno, vamos a ver un ejemplo acá tenemos factura con component y podemos cambiar para que en
vez de que sea Singleton sea del tipo RECUESTAN, entonces con request Scoob y vamos a importar.
Importábamos de Sprint.
Entonces ahora esta factura Steppings va a durar lo que dura una petición http de usuario.
Por lo tanto, cada usuario que se conecte va a tener una factura distinta y propia.
Por ejemplo, si modificamos un valor, ese valor no se altera, no se modifica al resto.
Vamos a ejecutar con clic derecho.
Ron as?
Guardame factura.
Y por ejemplo, voy a actualizar tres veces.
Cada actualización va concatenado el nombre, porque ahora el objeto se está construyendo en cada request,
en cada petición y no una sola vez como era en Singleton.
Y si vamos al terminal también por cada click, por cada refresh del navegador, va a mostrar el distraidos.
La factura fue destruida?
Claro, porque se inicia cuando comienza el request y se destruye cuando finaliza la petición HTTP y
es atómico único por cada usuario que se conecta y si se fija en cliente es singleton.
Entonces por eso el cliente va concatenado, porque es una instancia para la aplicación.
Entonces cada vez que se actualiza va agregando nuevamente el segundo nombre José.
Pero qué pasa si nos vamos a cliente y colocamos Scoob?
Hagamos la prueba ahora, tanto factura como cliente.
Los dos son del tipo de contexto.
Rico está ahora, claro, se va a crear y se va a destruir en cada request, pero no va a repetir la
concatenación.
Cliente también del mismo contexto que factura.
Actualizamos una vez, dos veces, tres veces, cuatro veces y cinco, y se mantiene como entre José.
Si vamos a terminal van a ir varios, pero siempre Andres, José se fijan Andres, José, uno por cada
recurso, por cada petición.
Bien, por lo tanto ambos componentes, tanto el padre, la factura como el hijo el cliente están dentro
del mismo contexto.
Por lo tanto, se crean dentro del Rickles ambos y no como antes.
El cliente estaba en un contexto diferente, en un contexto mucho más grande, mucho más amplio, que
es el singleton.
Entonces mantenía el valor anterior que íbamos modificando y concatenado y por eso se repetía siempre
el nombre una y otra vez.
Cada vez que actualizamos la página, nuevamente volvía a concatenar el nombre del valor anterior,
que está dentro de un contexto superior.
Pero ahora no están los dos dentro del mismo request.
Entonces hay que tener en cuenta esto, hay que darse cuenta de que factura en el request, pero si
cliente que estamos inyectando singleton siempre la misma instancia y va a obtener el nombre y le va
a concatenar cada vez que se crea factura.
Ahora, si los dos son del request, los dos se inician en el mismo contexto y ahí va a concatenar una
sola vez.
Bien.
Y también tenemos otra anotación de contexto.
En realidad tenemos sesión scope para traja concesiones y también a aplicar, por ejemplo.
Sesión, Scoob.
Básicamente la utilizamos para marcar nuestro objeto como de sesión.
Por ejemplo, si queremos trabajar con un carro de compra o con un sistema de autenticación y tenemos
la clase usuario, sea persistente en la sesión HTTP bueno, utilizamos sesiones co-op y típicamente
cuando trabajamos concesiones http el alcance o el ámbito del objeto, lo que dura una sesión desde
que se inicia, en este caso desde que se crea este componente en el contenedor del tipo sesión y se
va a destruir cuando cerremos el navegador.
Pero también finaliza cuando ocurre un time out o cuando se invalida la sesión.
Pero bien.
Un tema importante que hay que tener en cuenta en cualquier objeto clase componente que queramos guardar
en una sesión http debe implementar ser realizable la interfaz.
Bueno, por qué?
Porque cuando se transporta o se almacena un objeto de Java, por ejemplo, si lo queremos transportar,
guardar en la memoria o bien en un archivo XML o Jaison y también en sesiones HTTP.
Y después también vamos a ver otro ejemplo con Berner, después con JPA.
Los objetos entity que están mapeados átalas.
Estos se guardan en un contexto de persistencia, contexto propio del Horemheb de JPA y también necesitan
implementar la interfaz se realizable y es porque convierte el objeto en una secuencia de bits para
que se pueda guardar y transportar en estos tipos de almacenamiento.
Bueno, y justamente eso es el proceso de serialización.
Y después por supuesto que esta estructura que está centralizada, ya sea en la sesión HTTP o en un
Jaison, por ejemplo, o en el o RM, se va a restaurar en un objeto de yaba que es idéntico en todo
sentido al original.
Incluso el valor de sus atributos el estado interno.
Por lo tanto, este nuevo objeto es un clon perfecto del original.
Bien, vamos a implementar.
Entonces se realizará.
Qué importante para el scope sesión.
Vamos a importar.
Sea realizable.
Y acá nos pide acá se coloca la clase en amarillo, en un guarne, nos pide generar un ser Halverson.
Heidy Un identificador.
Seleccionamos Generar sería versión.
Colocamos yez.
O también podemos colocar el por defecto?
Da lo mismo.
No tiene ninguna importancia ni tampoco ningún impacto en nuestro código.
Es un atributo estático que lo maneja por debajo, como un identificador de la serialización.
Nada más.
Vamos a guardar.
Esperemos que se actualiza.
Y el ejemplo funciona tal cual.
Pero concesiones http.
Pero si se fijan acá concatenado el José en la descripción de la factura, porque la factura es de contexto
sesión.
Pero el cliente sigue estando en el recuesta en un contexto más acotado.
Un poco más pequeño.
Recordemos que un http cesion.
La persistencia de los datos o lo que van a durar los ojetes que están guardados en la sesión son varios
recuas.
No solamente uno.
Pueden estar varios recuas y va a durar hasta que ocurra un time out.
Cerremos el navegador o invalidamos la sesión.
Entonces, si queremos que se mantenga el cliente con Andrés José tendremos que cambiar.
Bueno, el alcance en sesión también porque está en.
Pero bueno, para el ejemplo da lo mismo si se fijan acá en la consola se crea una sesión HTTP.
Un sesión Heidy para este componente.
Ahora bien, cuando se destruye este componente de la sesión, el método anotado con Predi Strait no
se ejecuta ya porque la sesión http ese contexto lo maneja el servlet.
Lo vas a manejar esto.
Por lo tanto, en esta scoob o alcance no se aplica el Ristori, pero si el constructo el post construct
bien.
Y por último tenemos el apliqué hecho en Scoob, también lo podemos importar.
Bueno, es muy parecido al singleton.
Muy similar, pero se diferencia a que es un singleton que se guarda en el contexto servlet en el Saddleback
Context y no en el apliqué hecho con Tex de Spring.
Esa diferencia, por ejemplo, en una aplicación web con Spring vamos a tener siempre un solo aplicad
hecho en contexto, contexto, aplicación y ahí es Singleton.
Pero en una aplicación web podríamos tener más de un contexto Arlett.
Esa es la única diferencia.
Ahora lo normal por defecto de una aplicación es un Cerler Context por defecto, a menos que agreguemos
más, pero te lo dejamos por defecto.
Usar el apliqué hecho en Scoob o Singleton.
Es decir, no anotar nada es prácticamente lo mismo.
Bien, vamos a dejar en rico esto.
Íbamos a guardar, si ocurre un error.
No hay que tomarlo en cuenta, ya que era por la sesión.
Acá ocurre el error, pero básicamente era porque estaba guardado en el contexto de sesión y lo cambiamos
a recuas.
Da lo mismo cerrar.
Simplemente podemos incluso el local reiniciar restart para que refresque completamente el alcance.
Ya está perfecto.
Bien.
Vamos a quitar los import que nos estamos ocupando y dejamos solamente el recuesto y guardamos.
Y para finalizar, por último tenemos el contexto, el alcance prototype.
Pero en realidad no se aplica tanto a aplicaciones web con Spring MVC.
Más bien son para aplicaciones estándar halón, ya sea de consola, por ejemplo.
La única diferencia es que con Singleton tenemos una sola instancia en el contenedor y con Prototype
podemos tener más de una instancia del mismo Beans.
Pero bueno, por ahora nada más nos vemos.