1
00:00:00,300 --> 00:00:04,610
En esta clase vamos a ver el tema conceptual que hay detrás del MDC.

2
00:00:04,740 --> 00:00:09,750
El modelo vista controlador, pero primero vamos a partir por Spring MVC.

3
00:00:10,040 --> 00:00:13,740
Qué es y qué tiene que ver Spring MVC con Spring Framework?

4
00:00:13,950 --> 00:00:14,640
Es lo mismo.

5
00:00:14,920 --> 00:00:16,890
Bueno, y por supuesto que no es Spring.

6
00:00:17,850 --> 00:00:21,990
Es parte, es un componente del ecosistema de Spring Framework.

7
00:00:22,020 --> 00:00:28,170
Solamente una parte, porque también dentro de Spring Framework tenemos todo lo que a inyección de dependencias,

8
00:00:28,260 --> 00:00:33,540
que si bien se integra con Spring MS es un componente que es parte del core.

9
00:00:33,660 --> 00:00:37,440
También tenemos todo lo que es integración con o R.M.

10
00:00:37,500 --> 00:00:40,350
Trabajar con base datos mediante JDBC.

11
00:00:40,440 --> 00:00:42,810
Todo lo que es programación orientada a aspectos.

12
00:00:42,870 --> 00:00:48,450
En fin, hay un montón de cosas webs, socket, spring security, en fin, y mucho más.

13
00:00:48,510 --> 00:00:50,190
Pero bien, centrémonos en Spring.

14
00:00:50,300 --> 00:00:55,080
MS Es un framework web, un componente parte de Spring Frenkel.

15
00:00:55,170 --> 00:01:00,990
Por supuesto que está basado en la arquitectura modelo vista controlador y toma como ventajas.

16
00:01:01,080 --> 00:01:08,160
Incluye los siguientes principios de partida Bueno LMS separación de capas modelo por un lado, la vista

17
00:01:08,160 --> 00:01:13,800
por otro y el controlador, pero además se integra con el contexto de inyección de dependencias.

18
00:01:13,890 --> 00:01:16,650
Eso también lo vamos a ver en el curso próximamente.

19
00:01:16,770 --> 00:01:18,930
Orientado al uso de interfaces.

20
00:01:19,050 --> 00:01:25,290
Está muy conectado con inyección de dependencia porque podemos inyectar un componente a través de su

21
00:01:25,290 --> 00:01:28,650
interfaz y no a través de su tipo concreto.

22
00:01:28,680 --> 00:01:34,830
La idea es desacoplar la implementación concreta y utilizar tipos más abstractos en el día mañana.

23
00:01:34,920 --> 00:01:40,290
Nuestra implementación, nuestra clase concreta que estemos utilizando, por ejemplo, de un acceso

24
00:01:40,290 --> 00:01:47,030
a datos podría cambiar y eso implica tener que modificar todas las clases y código donde se está utilizando,

25
00:01:47,130 --> 00:01:53,070
mientras con interfaces es mucho más genérico, mucho más abstracto y solamente implementamos una nueva

26
00:01:53,070 --> 00:01:54,430
clase de esa interfaz.

27
00:01:54,480 --> 00:01:56,160
Pero ese tipo abstracto se mantiene.

28
00:01:56,220 --> 00:01:57,900
Pero bueno, cosas que vamos a ver después.

29
00:01:57,990 --> 00:02:03,450
Uso de clases POJO clases simple de Java con atributos y métodos Kether y Z.

30
00:02:03,570 --> 00:02:11,130
Desacoplar completamente de los framework no implementa ninguna interfaz o clases de framework o de

31
00:02:11,130 --> 00:02:13,170
API y son muy reutilizables.

32
00:02:13,260 --> 00:02:15,690
Representan los datos de nuestra aplicación.

33
00:02:15,780 --> 00:02:20,040
Típicamente lo utilizamos con JPA cuando mapeados a las tablas.

34
00:02:20,160 --> 00:02:26,190
Después vamos a ver que la clase Identity que están mapeados a tablas de la base datos son clases de

35
00:02:26,190 --> 00:02:27,450
internet de JPA.

36
00:02:27,540 --> 00:02:28,890
Finalmente son POJO.

37
00:02:28,980 --> 00:02:36,240
Son clases simple de Java con atributos y sus jeeter y Z, cosa que después vamos a ver por ahora LMS

38
00:02:36,600 --> 00:02:37,520
mucho más allá.

39
00:02:37,530 --> 00:02:45,300
Un patrón de diseño es un patrón de arquitectura, ya que internamente engloba a varios patrones de

40
00:02:45,300 --> 00:02:47,880
diseño, es decir, está formado por varios patrones.

41
00:02:48,000 --> 00:02:54,630
No solamente uno es un patrón de arquitectura, es una parte importante de un framework web.

42
00:02:54,870 --> 00:02:58,230
Separa nuestra aplicación en tres grandes component.

43
00:02:58,350 --> 00:03:01,830
Por un lado tenemos el controlador, tenemos la vista y el modelo.

44
00:03:02,040 --> 00:03:08,640
El usuario a través de una Gabor interactúa directamente con el controlador enviando solicitudes peticiones

45
00:03:08,700 --> 00:03:09,480
http.

46
00:03:09,540 --> 00:03:14,370
Por lo tanto, hay una comunicación entre el navegador el cliente con el controlador.

47
00:03:14,460 --> 00:03:18,900
El controlador va a recibir estas peticiones de usuarios, la va a manejar.

48
00:03:18,960 --> 00:03:25,800
Por ejemplo, si el usuario le envía un Heidy, un dato va a tomar Estadi y va a ir a buscar un registro

49
00:03:25,890 --> 00:03:26,310
a la base.

50
00:03:26,310 --> 00:03:33,000
Dato El cliente está solicitando un dato, un registro mediante un Heidy controlador interactúa con

51
00:03:33,000 --> 00:03:33,510
el modelo.

52
00:03:33,630 --> 00:03:41,310
Entonces el modelo ya se encarga de trabajar con los datos, ya sea consultas, operaciones, select,

53
00:03:41,490 --> 00:03:45,390
actualizaciones con INSER, con APDAYC, con Delight, ID, en fin.

54
00:03:45,480 --> 00:03:51,690
Y todo esto lo hace a través de otros componentes, clases como el acceso a datos o los datos o repository

55
00:03:51,780 --> 00:03:56,130
clase servis que agrupan varios datos, manejan transacciones.

56
00:03:56,190 --> 00:04:01,560
En fin, el modelo se refiere a la lógica de negocio, a los datos de nuestra aplicación.

57
00:04:01,680 --> 00:04:08,970
Estos datos regresan al controlador, el controlador se lo pasa a la vista y la vista es la que se encarga

58
00:04:09,030 --> 00:04:14,400
de renderizar, de mostrar los datos del modelo y por eso acá tenemos estas relaciones.

59
00:04:14,790 --> 00:04:22,380
El controlador obtiene datos de la lógica de negocio, el modelo y se lo pasa a la vista.

60
00:04:22,770 --> 00:04:24,690
Renderiza estos datos en la vista.

61
00:04:24,840 --> 00:04:28,740
Por lo tanto, la vista ya tiene acceso a este objeto del modelo.

62
00:04:28,830 --> 00:04:33,660
Por ejemplo, con sus atributos getter y setters y puede mostrar estos datos del modelo.

63
00:04:33,810 --> 00:04:39,600
Si trabajamos con hiberna con JPA cosas que vamos a ver, el modelo básicamente sería nuestras clases

64
00:04:39,600 --> 00:04:43,800
ENTITY, que también son pujos con atributos, métodos, grilletes.

65
00:04:43,890 --> 00:04:48,270
Por lo tanto, la vista puede mostrar los datos de esta clase Entity.

66
00:04:48,750 --> 00:04:53,670
Y una vista no solamente puede mostrarse, sino que también puede enviar datos al controlador.

67
00:04:53,760 --> 00:04:56,160
Por ejemplo, una vista que es un formulario.

68
00:04:56,310 --> 00:04:59,820
Ahí tenemos el proceso inverso que iría desde la vista.

69
00:05:00,040 --> 00:05:02,200
Al controlador hacemos un submit.

70
00:05:02,260 --> 00:05:08,620
Una petición HTTP del tipo post, como por ejemplo el usuario carga un formulario, hace una solicitud,

71
00:05:08,770 --> 00:05:15,280
el controlador la recibe, muestra el formulario y después con un clic en el botón Enviar se envía el

72
00:05:15,280 --> 00:05:17,860
formulario, pero del tipo post lo recibe.

73
00:05:17,860 --> 00:05:20,710
El controlador obtiene los datos del formulario.

74
00:05:20,770 --> 00:05:27,750
Estos datos se van a poblar dentro del objeto del modelo y si persisten o se actualizan enlaces.

75
00:05:28,060 --> 00:05:33,910
Por lo tanto, el modelo constantemente está interactuando y está mapeado a tablas.

76
00:05:34,030 --> 00:05:34,720
Enlace atto.

77
00:05:34,990 --> 00:05:36,520
Cómo funciona spring m%s.

78
00:05:36,610 --> 00:05:39,490
Bueno, primero existe un front controller.

79
00:05:39,610 --> 00:05:43,290
Es un patrón de diseño que está dentro de spring mבs.

80
00:05:43,420 --> 00:05:44,260
Este componente.

81
00:05:44,260 --> 00:05:47,500
Este patrón se encarga de recibir estas solicitudes.

82
00:05:47,590 --> 00:05:52,330
HTTP del cliente del usuario obtiene esta ruta VL.

83
00:05:52,420 --> 00:05:55,900
Recordemos que los controladores están mapeados a rutas jureles.

84
00:05:56,020 --> 00:05:57,040
Obtiene esta ruta.

85
00:05:57,130 --> 00:06:03,910
Iba a buscar el controlador que corresponde a esta ruta y le asigna el request a este controlar para

86
00:06:03,910 --> 00:06:06,880
obtener los datos los parámetros que se están enviando.

87
00:06:07,030 --> 00:06:13,870
Recordemos que esta ruta se mapear con Rico es mapping con Quiet Mapping o Post Mapping, dependiendo

88
00:06:13,960 --> 00:06:17,470
el verbo o tipo de la petición http.

89
00:06:17,590 --> 00:06:20,590
El método el controlador también interactúa.

90
00:06:20,590 --> 00:06:27,460
Se relaciona con la lógica negocio clase servis o de acceso dato y por ejemplo, obtiene estos datos

91
00:06:27,460 --> 00:06:30,580
a través de una consulta y se lo envía a la vista.

92
00:06:30,760 --> 00:06:35,650
Le pasa estos datos a la vista para que muestre estos datos del modelo a la vista.

93
00:06:35,800 --> 00:06:36,550
Y cómo se lo pasa?

94
00:06:36,590 --> 00:06:44,770
Bueno, eso ya lo vimos utilizando el model Model and view, el map de Yaba, el Model Map, en fin,

95
00:06:44,950 --> 00:06:50,710
el controlador retorna o asigna el nombre lógico de la vista que va a mostrar.

96
00:06:50,800 --> 00:06:51,700
Eso también lo vimos.

97
00:06:51,760 --> 00:06:55,300
Recordemos que el método Handler retorna un string.

98
00:06:55,450 --> 00:07:01,600
En ese string indicamos el nombre la vista de forma interna, porque esto no se ve en el framework,

99
00:07:01,690 --> 00:07:08,260
lo maneja de forma implícita, pero hay un view resolver un manejador que resuelve la vista por defecto.

100
00:07:08,380 --> 00:07:13,570
La vista es HTML si estamos trabajando con Tinduf, pero también podemos configurar para que nuestra

101
00:07:13,570 --> 00:07:20,920
vista también sea del tipo PDF o un Excel o cualquier otro tipo, un archivo plano o lo que sea, también

102
00:07:20,920 --> 00:07:22,390
lo veremos más adelante.

103
00:07:22,480 --> 00:07:29,080
Finalmente, la vista mostrada al cliente usando los datos del objeto model bien una característica

104
00:07:29,170 --> 00:07:32,980
en la clara separación de funciones dentro de MS.

105
00:07:33,070 --> 00:07:36,190
Por un lado, tenemos los controladores que se encargan de ciertas tareas.

106
00:07:36,250 --> 00:07:42,220
Por otro lado tenemos los validad ores que se encargan de validar el formulario, los datos que recibe

107
00:07:42,220 --> 00:07:42,970
el controlador.

108
00:07:43,030 --> 00:07:48,310
Por otro lado, tenemos el objeto de formulario que está mapeado también a la lógica de negocio.

109
00:07:48,460 --> 00:07:49,390
Es bidireccional.

110
00:07:49,480 --> 00:07:55,120
Por lo general, el objeto de formulario, que también se le conoce como objeto de comando, está mapeado

111
00:07:55,120 --> 00:08:00,220
tanto a la tabla de la base dato como también a los campos del formulario.

112
00:08:00,340 --> 00:08:07,510
Luego tenemos el despachen cerle nuestro fueron controles que es el encargado como vimos de seleccionar

113
00:08:07,510 --> 00:08:15,070
el controlador y su método handler según la ruta U rl los Handler Mapping es la ruta de mapeo que tiene

114
00:08:15,070 --> 00:08:17,650
cada método de acción del controlador.

115
00:08:17,800 --> 00:08:24,610
Lo podemos configurar o mapear con la anotación Request Mapping o Get Mapping o Post Mapping.

116
00:08:24,700 --> 00:08:31,000
También tenemos los View Resolver que se encarga de resolver la vista a cargar, ya sea por el nombre

117
00:08:31,120 --> 00:08:32,860
y también el tipo de vistas.

118
00:08:32,950 --> 00:08:39,400
Si queremos renderizar un HTML común y corriente con left o un PDF, un Excel, un archivo plano, un

119
00:08:39,400 --> 00:08:45,970
Jason, en fin, entonces cada uno de estos componentes de estas partes de Spring mבs llevan a cabo

120
00:08:46,090 --> 00:08:53,080
diferentes tareas y cada tarea muy específica en cada uno de estos y pueden ser reemplazables sin afectar

121
00:08:53,200 --> 00:08:54,340
a los demás componentes.

122
00:08:54,490 --> 00:08:56,770
Y para finalizar lo que hace un controlador.

123
00:08:56,980 --> 00:09:03,880
Ya hemos mencionado que se encarga de manejar las solicitudes de los usuarios, pero además proporcionan

124
00:09:03,940 --> 00:09:05,920
acceso a la lógica de negocio.

125
00:09:06,100 --> 00:09:10,630
Delegas la lógica de negocio a un conjunto de clases de servicio.

126
00:09:10,780 --> 00:09:11,560
Los servicios.

127
00:09:11,620 --> 00:09:17,170
Estas clases servis a su vez tienen acceso a la base de datos mediante los datos o repository.

128
00:09:17,290 --> 00:09:21,850
La interfaz de acceso a datos los controladores reside en parámetros de los usuarios.

129
00:09:21,940 --> 00:09:29,980
Los input a través de formulario o parámetros de la ruta Vll y los convierten en un objeto del modelo

130
00:09:30,070 --> 00:09:37,360
poblando en sus atributos estos datos enviados y después los datos se pueden actualizar o persistir

131
00:09:37,450 --> 00:09:38,580
en nuestra base.

132
00:09:39,310 --> 00:09:42,130
Me despido y nos vemos en la próxima clase.