1
00:00:00,330 --> 00:00:06,630
Bienvenidos en esta clase vamos a hablar sobre los distintos contexto o alcance de los componentes.

2
00:00:06,900 --> 00:00:14,280
El Scoob que se le llama por defecto vimos que son del tipo singleton, es decir, vaban tener en el

3
00:00:14,280 --> 00:00:18,570
contenedor de Spring una sola instancia de ese componente por defecto.

4
00:00:18,750 --> 00:00:23,910
Y no solamente se aplica a factura que está anotado con component, sino también a los controladores.

5
00:00:24,030 --> 00:00:31,060
Por ejemplo, si nos vamos a controllers factura controllers, un controlador que también es un componente

6
00:00:31,060 --> 00:00:36,330
de Spring también en el contexto o scope singleton.

7
00:00:36,510 --> 00:00:42,630
Vamos a tener una sola instancia de ese controlador para toda la aplicación y se va a utilizar en cada

8
00:00:42,630 --> 00:00:47,220
request en cada petición de los distintos clientes que estén usando esta aplicación.

9
00:00:47,370 --> 00:00:53,430
Ese por defecto igual se puede cambiar a un contexto, por ejemplo del request o de sesión.

10
00:00:53,520 --> 00:01:00,450
Hay que tener cuidado y presente que cuando es singleton el por defecto, no podemos tener atributos

11
00:01:00,510 --> 00:01:06,810
en el controlador que sea propio del usuario, ya que también podrían ser modificados por otros usuarios

12
00:01:06,810 --> 00:01:07,770
por otras peticiones.

13
00:01:07,860 --> 00:01:12,780
Entonces la idea es que todos estos objetos que inyectamos sean styles.

14
00:01:12,960 --> 00:01:19,110
Es decir, sin estado que no mantenga estado, no mantenga valores en los atributos o información del

15
00:01:19,110 --> 00:01:19,450
usuario.

16
00:01:19,500 --> 00:01:22,920
Como sería una sesión, un carro de compra, por ejemplo.

17
00:01:23,070 --> 00:01:29,370
Para eso utilizamos otro contexto que sería, por ejemplo del Rickert o como había mencionado, del

18
00:01:29,370 --> 00:01:31,170
tipo sesión de sesión.

19
00:01:31,290 --> 00:01:37,740
Pero bueno, vamos a ver un ejemplo acá tenemos factura con component y podemos cambiar para que en

20
00:01:37,740 --> 00:01:47,040
vez de que sea Singleton sea del tipo RECUESTAN, entonces con request Scoob y vamos a importar.

21
00:01:49,350 --> 00:01:50,550
Importábamos de Sprint.

22
00:01:51,030 --> 00:01:57,330
Entonces ahora esta factura Steppings va a durar lo que dura una petición http de usuario.

23
00:01:57,480 --> 00:02:02,820
Por lo tanto, cada usuario que se conecte va a tener una factura distinta y propia.

24
00:02:03,210 --> 00:02:08,550
Por ejemplo, si modificamos un valor, ese valor no se altera, no se modifica al resto.

25
00:02:08,790 --> 00:02:10,950
Vamos a ejecutar con clic derecho.

26
00:02:12,410 --> 00:02:13,160
Ron as?

27
00:02:15,670 --> 00:02:16,630
Guardame factura.

28
00:02:19,700 --> 00:02:21,440
Y por ejemplo, voy a actualizar tres veces.

29
00:02:23,690 --> 00:02:29,800
Cada actualización va concatenado el nombre, porque ahora el objeto se está construyendo en cada request,

30
00:02:29,890 --> 00:02:33,010
en cada petición y no una sola vez como era en Singleton.

31
00:02:33,280 --> 00:02:40,270
Y si vamos al terminal también por cada click, por cada refresh del navegador, va a mostrar el distraidos.

32
00:02:40,750 --> 00:02:41,770
La factura fue destruida?

33
00:02:41,800 --> 00:02:48,430
Claro, porque se inicia cuando comienza el request y se destruye cuando finaliza la petición HTTP y

34
00:02:48,430 --> 00:02:54,760
es atómico único por cada usuario que se conecta y si se fija en cliente es singleton.

35
00:02:54,940 --> 00:02:59,980
Entonces por eso el cliente va concatenado, porque es una instancia para la aplicación.

36
00:03:00,040 --> 00:03:04,960
Entonces cada vez que se actualiza va agregando nuevamente el segundo nombre José.

37
00:03:04,990 --> 00:03:08,550
Pero qué pasa si nos vamos a cliente y colocamos Scoob?

38
00:03:08,980 --> 00:03:12,700
Hagamos la prueba ahora, tanto factura como cliente.

39
00:03:12,760 --> 00:03:15,070
Los dos son del tipo de contexto.

40
00:03:15,130 --> 00:03:22,000
Rico está ahora, claro, se va a crear y se va a destruir en cada request, pero no va a repetir la

41
00:03:22,000 --> 00:03:22,750
concatenación.

42
00:03:22,810 --> 00:03:25,330
Cliente también del mismo contexto que factura.

43
00:03:26,400 --> 00:03:31,920
Actualizamos una vez, dos veces, tres veces, cuatro veces y cinco, y se mantiene como entre José.

44
00:03:32,040 --> 00:03:39,210
Si vamos a terminal van a ir varios, pero siempre Andres, José se fijan Andres, José, uno por cada

45
00:03:39,300 --> 00:03:41,130
recurso, por cada petición.

46
00:03:41,260 --> 00:03:47,490
Bien, por lo tanto ambos componentes, tanto el padre, la factura como el hijo el cliente están dentro

47
00:03:47,490 --> 00:03:48,570
del mismo contexto.

48
00:03:48,630 --> 00:03:53,130
Por lo tanto, se crean dentro del Rickles ambos y no como antes.

49
00:03:53,220 --> 00:03:58,710
El cliente estaba en un contexto diferente, en un contexto mucho más grande, mucho más amplio, que

50
00:03:58,710 --> 00:03:59,460
es el singleton.

51
00:03:59,610 --> 00:04:06,210
Entonces mantenía el valor anterior que íbamos modificando y concatenado y por eso se repetía siempre

52
00:04:06,330 --> 00:04:07,830
el nombre una y otra vez.

53
00:04:07,830 --> 00:04:13,680
Cada vez que actualizamos la página, nuevamente volvía a concatenar el nombre del valor anterior,

54
00:04:13,770 --> 00:04:15,450
que está dentro de un contexto superior.

55
00:04:15,510 --> 00:04:19,260
Pero ahora no están los dos dentro del mismo request.

56
00:04:21,020 --> 00:04:25,430
Entonces hay que tener en cuenta esto, hay que darse cuenta de que factura en el request, pero si

57
00:04:25,430 --> 00:04:32,570
cliente que estamos inyectando singleton siempre la misma instancia y va a obtener el nombre y le va

58
00:04:32,570 --> 00:04:35,240
a concatenar cada vez que se crea factura.

59
00:04:35,510 --> 00:04:40,670
Ahora, si los dos son del request, los dos se inician en el mismo contexto y ahí va a concatenar una

60
00:04:40,670 --> 00:04:41,120
sola vez.

61
00:04:41,330 --> 00:04:41,600
Bien.

62
00:04:41,690 --> 00:04:45,080
Y también tenemos otra anotación de contexto.

63
00:04:45,260 --> 00:04:50,840
En realidad tenemos sesión scope para traja concesiones y también a aplicar, por ejemplo.

64
00:04:54,870 --> 00:04:55,950
Sesión, Scoob.

65
00:04:57,170 --> 00:05:01,100
Básicamente la utilizamos para marcar nuestro objeto como de sesión.

66
00:05:01,130 --> 00:05:06,530
Por ejemplo, si queremos trabajar con un carro de compra o con un sistema de autenticación y tenemos

67
00:05:06,590 --> 00:05:13,340
la clase usuario, sea persistente en la sesión HTTP bueno, utilizamos sesiones co-op y típicamente

68
00:05:13,400 --> 00:05:20,540
cuando trabajamos concesiones http el alcance o el ámbito del objeto, lo que dura una sesión desde

69
00:05:20,540 --> 00:05:25,850
que se inicia, en este caso desde que se crea este componente en el contenedor del tipo sesión y se

70
00:05:25,850 --> 00:05:28,000
va a destruir cuando cerremos el navegador.

71
00:05:28,100 --> 00:05:33,060
Pero también finaliza cuando ocurre un time out o cuando se invalida la sesión.

72
00:05:33,170 --> 00:05:33,770
Pero bien.

73
00:05:33,890 --> 00:05:39,590
Un tema importante que hay que tener en cuenta en cualquier objeto clase componente que queramos guardar

74
00:05:39,680 --> 00:05:44,180
en una sesión http debe implementar ser realizable la interfaz.

75
00:05:44,260 --> 00:05:45,200
Bueno, por qué?

76
00:05:45,290 --> 00:05:51,890
Porque cuando se transporta o se almacena un objeto de Java, por ejemplo, si lo queremos transportar,

77
00:05:51,920 --> 00:05:58,850
guardar en la memoria o bien en un archivo XML o Jaison y también en sesiones HTTP.

78
00:05:59,000 --> 00:06:03,410
Y después también vamos a ver otro ejemplo con Berner, después con JPA.

79
00:06:03,530 --> 00:06:06,380
Los objetos entity que están mapeados átalas.

80
00:06:06,470 --> 00:06:14,180
Estos se guardan en un contexto de persistencia, contexto propio del Horemheb de JPA y también necesitan

81
00:06:14,300 --> 00:06:20,090
implementar la interfaz se realizable y es porque convierte el objeto en una secuencia de bits para

82
00:06:20,090 --> 00:06:24,080
que se pueda guardar y transportar en estos tipos de almacenamiento.

83
00:06:24,210 --> 00:06:27,740
Bueno, y justamente eso es el proceso de serialización.

84
00:06:27,920 --> 00:06:34,370
Y después por supuesto que esta estructura que está centralizada, ya sea en la sesión HTTP o en un

85
00:06:34,370 --> 00:06:40,760
Jaison, por ejemplo, o en el o RM, se va a restaurar en un objeto de yaba que es idéntico en todo

86
00:06:40,760 --> 00:06:41,990
sentido al original.

87
00:06:42,110 --> 00:06:45,260
Incluso el valor de sus atributos el estado interno.

88
00:06:45,350 --> 00:06:49,820
Por lo tanto, este nuevo objeto es un clon perfecto del original.

89
00:06:49,980 --> 00:06:51,080
Bien, vamos a implementar.

90
00:06:51,080 --> 00:06:52,310
Entonces se realizará.

91
00:06:52,370 --> 00:06:55,070
Qué importante para el scope sesión.

92
00:06:58,460 --> 00:06:59,300
Vamos a importar.

93
00:06:59,360 --> 00:07:00,170
Sea realizable.

94
00:07:01,920 --> 00:07:08,760
Y acá nos pide acá se coloca la clase en amarillo, en un guarne, nos pide generar un ser Halverson.

95
00:07:08,800 --> 00:07:10,440
Heidy Un identificador.

96
00:07:10,530 --> 00:07:12,450
Seleccionamos Generar sería versión.

97
00:07:13,780 --> 00:07:14,740
Colocamos yez.

98
00:07:16,180 --> 00:07:18,010
O también podemos colocar el por defecto?

99
00:07:18,220 --> 00:07:18,820
Da lo mismo.

100
00:07:21,370 --> 00:07:25,930
No tiene ninguna importancia ni tampoco ningún impacto en nuestro código.

101
00:07:26,050 --> 00:07:31,660
Es un atributo estático que lo maneja por debajo, como un identificador de la serialización.

102
00:07:31,840 --> 00:07:32,350
Nada más.

103
00:07:32,470 --> 00:07:33,370
Vamos a guardar.

104
00:07:35,180 --> 00:07:36,160
Esperemos que se actualiza.

105
00:07:38,010 --> 00:07:40,110
Y el ejemplo funciona tal cual.

106
00:07:40,170 --> 00:07:42,250
Pero concesiones http.

107
00:07:42,540 --> 00:07:48,720
Pero si se fijan acá concatenado el José en la descripción de la factura, porque la factura es de contexto

108
00:07:48,720 --> 00:07:49,140
sesión.

109
00:07:49,200 --> 00:07:53,970
Pero el cliente sigue estando en el recuesta en un contexto más acotado.

110
00:07:54,030 --> 00:07:54,840
Un poco más pequeño.

111
00:07:54,870 --> 00:07:57,000
Recordemos que un http cesion.

112
00:07:57,120 --> 00:08:02,130
La persistencia de los datos o lo que van a durar los ojetes que están guardados en la sesión son varios

113
00:08:02,130 --> 00:08:02,470
recuas.

114
00:08:02,580 --> 00:08:03,480
No solamente uno.

115
00:08:03,570 --> 00:08:07,920
Pueden estar varios recuas y va a durar hasta que ocurra un time out.

116
00:08:08,070 --> 00:08:10,890
Cerremos el navegador o invalidamos la sesión.

117
00:08:11,350 --> 00:08:15,810
Entonces, si queremos que se mantenga el cliente con Andrés José tendremos que cambiar.

118
00:08:15,900 --> 00:08:20,490
Bueno, el alcance en sesión también porque está en.

119
00:08:21,600 --> 00:08:29,220
Pero bueno, para el ejemplo da lo mismo si se fijan acá en la consola se crea una sesión HTTP.

120
00:08:29,310 --> 00:08:31,350
Un sesión Heidy para este componente.

121
00:08:31,560 --> 00:08:38,640
Ahora bien, cuando se destruye este componente de la sesión, el método anotado con Predi Strait no

122
00:08:38,640 --> 00:08:44,010
se ejecuta ya porque la sesión http ese contexto lo maneja el servlet.

123
00:08:44,160 --> 00:08:45,210
Lo vas a manejar esto.

124
00:08:45,450 --> 00:08:52,800
Por lo tanto, en esta scoob o alcance no se aplica el Ristori, pero si el constructo el post construct

125
00:08:53,280 --> 00:08:53,460
bien.

126
00:08:53,550 --> 00:08:59,580
Y por último tenemos el apliqué hecho en Scoob, también lo podemos importar.

127
00:09:01,170 --> 00:09:03,720
Bueno, es muy parecido al singleton.

128
00:09:03,810 --> 00:09:10,230
Muy similar, pero se diferencia a que es un singleton que se guarda en el contexto servlet en el Saddleback

129
00:09:10,260 --> 00:09:14,070
Context y no en el apliqué hecho con Tex de Spring.

130
00:09:14,250 --> 00:09:19,860
Esa diferencia, por ejemplo, en una aplicación web con Spring vamos a tener siempre un solo aplicad

131
00:09:19,860 --> 00:09:22,950
hecho en contexto, contexto, aplicación y ahí es Singleton.

132
00:09:23,070 --> 00:09:26,640
Pero en una aplicación web podríamos tener más de un contexto Arlett.

133
00:09:26,790 --> 00:09:27,700
Esa es la única diferencia.

134
00:09:27,810 --> 00:09:34,290
Ahora lo normal por defecto de una aplicación es un Cerler Context por defecto, a menos que agreguemos

135
00:09:34,290 --> 00:09:36,270
más, pero te lo dejamos por defecto.

136
00:09:36,390 --> 00:09:38,850
Usar el apliqué hecho en Scoob o Singleton.

137
00:09:38,970 --> 00:09:42,030
Es decir, no anotar nada es prácticamente lo mismo.

138
00:09:42,280 --> 00:09:44,130
Bien, vamos a dejar en rico esto.

139
00:09:48,680 --> 00:09:51,870
Íbamos a guardar, si ocurre un error.

140
00:09:52,100 --> 00:09:54,710
No hay que tomarlo en cuenta, ya que era por la sesión.

141
00:09:55,250 --> 00:10:01,160
Acá ocurre el error, pero básicamente era porque estaba guardado en el contexto de sesión y lo cambiamos

142
00:10:01,250 --> 00:10:01,790
a recuas.

143
00:10:01,940 --> 00:10:02,750
Da lo mismo cerrar.

144
00:10:02,870 --> 00:10:10,400
Simplemente podemos incluso el local reiniciar restart para que refresque completamente el alcance.

145
00:10:11,420 --> 00:10:12,390
Ya está perfecto.

146
00:10:12,730 --> 00:10:12,970
Bien.

147
00:10:14,240 --> 00:10:21,470
Vamos a quitar los import que nos estamos ocupando y dejamos solamente el recuesto y guardamos.

148
00:10:21,740 --> 00:10:26,720
Y para finalizar, por último tenemos el contexto, el alcance prototype.

149
00:10:26,840 --> 00:10:31,190
Pero en realidad no se aplica tanto a aplicaciones web con Spring MVC.

150
00:10:31,310 --> 00:10:36,050
Más bien son para aplicaciones estándar halón, ya sea de consola, por ejemplo.

151
00:10:36,170 --> 00:10:40,820
La única diferencia es que con Singleton tenemos una sola instancia en el contenedor y con Prototype

152
00:10:40,880 --> 00:10:44,350
podemos tener más de una instancia del mismo Beans.

153
00:10:44,510 --> 00:10:46,940
Pero bueno, por ahora nada más nos vemos.