1
00:00:10,570 --> 00:00:12,550
Hola te saluda Ubal lacosta.

2
00:00:13,210 --> 00:00:14,610
Bienvenidos nuevamente.

3
00:00:14,980 --> 00:00:18,130
Espero que estén listos para comenzar con esta elección.

4
00:00:18,130 --> 00:00:23,570
A continuación vamos a estudiar la lección de patrón de diseño MBC están listos.

5
00:00:23,620 --> 00:00:32,070
Vamos conceptos del patrón de diseño MBC en esta elección vamos a revisar los conceptos del patrón de

6
00:00:32,070 --> 00:00:40,120
diseño modelo vista controlador también conocido como MBC un patrón de diseño permite solucionar problemas

7
00:00:40,120 --> 00:00:45,990
comunes que se presentan al momento de crear aplicaciones y en particular en aplicaciones web.

8
00:00:46,030 --> 00:00:51,880
Nos interesa separar la vista de los datos y unirlos por medio de un componente que hace las veces del

9
00:00:51,880 --> 00:00:58,840
controlador y los datos hacen las veces del modelo según hemos estudiado hasta el momento los servlets

10
00:00:58,990 --> 00:01:05,950
están enfocados en controlar el flujo de la aplicación web y en este caso procesan las peticiones HTTP

11
00:01:06,640 --> 00:01:12,550
así como también utilizan los JavaBeans para almacenar la información y finalmente redireccionar al

12
00:01:12,550 --> 00:01:20,710
JSP respectivo los JSP están enfocados en desplegar la información de la aplicación web en este caso

13
00:01:20,710 --> 00:01:26,710
la información es proveída por medio de los servlets y la información que se comparte entre estos componentes

14
00:01:26,980 --> 00:01:35,270
es decir entre los servlets y jote Sepes suele manejarse con Java Vins así que la información compartida

15
00:01:35,300 --> 00:01:43,290
entre los servlets y JSP es normalmente la vamos a compartir utilizando ya babys el patrón de diseño

16
00:01:43,350 --> 00:01:46,520
MVC nos permite integrar a los JSP.

17
00:01:46,620 --> 00:01:54,630
Es decir la vista a los servlets es decir el controlador y a los JavaBeans es decir el modelo para poder

18
00:01:54,690 --> 00:01:59,760
interactuar y así crear aplicaciones web cada vez más robustas y más fáciles de mantener

19
00:02:03,580 --> 00:02:11,190
freímos que utilizan el patrón MVC tenemos varios freímos que utilizan la tecnología o que podemos implementar

20
00:02:11,250 --> 00:02:17,940
el patrón MVC por ejemplo cuando trabajamos con JCP y servlets se implementa manualmente con ayuda del

21
00:02:17,940 --> 00:02:22,730
objeto recuas despachar para controlar el flujo de la aplicación.

22
00:02:22,740 --> 00:02:25,170
También tenemos por ejemplo el freímos destruí.

23
00:02:25,380 --> 00:02:30,800
Este es un framework de Apache el cual utiliza JSP como una vista con tags destruídos.

24
00:02:30,840 --> 00:02:37,350
También utiliza el concepto de Action form que representa el modelo y también la clase Action la cual

25
00:02:37,380 --> 00:02:45,870
hace las veces del controlador entre otros componentes que nos facilitan el patrón de diseño MVC llama

26
00:02:45,940 --> 00:02:46,670
Seven Faces.

27
00:02:46,690 --> 00:02:52,240
Es otra tecnología que utiliza conceptos como JSP con tags de JSF.

28
00:02:52,240 --> 00:02:54,040
También aplica el concepto de Manas.

29
00:02:54,160 --> 00:03:02,170
Es decir el controlador y JavaBeans que utiliza el modelo MVC es una extensión del freímos de Spring

30
00:03:02,530 --> 00:03:09,390
que utiliza JSP como la vista con tags de Spring clases Java controladores y JavaBeans que son el modelo.

31
00:03:09,460 --> 00:03:15,550
Existen muchos más freímos IAVA que implementan el patrón MVC así que estos son tan solo algunos de

32
00:03:15,550 --> 00:03:17,470
los más representativos.

33
00:03:17,680 --> 00:03:23,740
Un patrón de diseño simplemente es una guía general y cada Framework define la especificación según

34
00:03:23,740 --> 00:03:27,820
las mejores prácticas desde el punto de vista de cada framework.

35
00:03:27,850 --> 00:03:34,210
Por ello es que tenemos muchas implementaciones del patrón de diseño MVC ya que simplemente es una guía

36
00:03:34,420 --> 00:03:38,370
y cada Framework lo implementa a la manera que mejor le parece.

37
00:03:38,410 --> 00:03:41,110
Para representar este patrón de diseño MVC

38
00:03:44,190 --> 00:03:51,130
arquitectura MVC con jote Cepes y servlets vamos a comentar ahora la arquitectura utilizando jote Sepes

39
00:03:51,200 --> 00:03:53,000
y servlets.

40
00:03:53,000 --> 00:03:57,000
Como podemos observar el flujo inicia con un formulario HTML.

41
00:03:57,140 --> 00:04:02,780
Esta información está almacenada en nuestro cliente y del lado derecho tenemos el servidor.

42
00:04:02,780 --> 00:04:08,180
Una vez que nuestro cliente envía la petición del formulario hacia el servidor web quién va a procesar

43
00:04:08,210 --> 00:04:09,040
esta petición.

44
00:04:09,050 --> 00:04:16,640
Es un Servlet es decir el controlador y a pesar que en ejercicios anteriores hemos colocado a un JSP

45
00:04:16,670 --> 00:04:19,130
para manejar directamente formularios.

46
00:04:19,130 --> 00:04:25,910
Según comentamos esto no es una buena práctica por lo tanto las peticiones las debe de procesar un controlador

47
00:04:26,450 --> 00:04:31,570
incluso en el diagrama podemos observar los números con los cuales vamos a ir siguiendo nuestro flujo.

48
00:04:31,790 --> 00:04:34,660
En este caso los números del 1 al 5.

49
00:04:34,880 --> 00:04:37,800
Una vez que se habla el controlador ha recibido la petición.

50
00:04:37,940 --> 00:04:44,420
Una de sus tareas puede ser procesar los parámetros del formulario HTML si es que aplica y una vez que

51
00:04:44,420 --> 00:04:50,450
ya tenemos procesado los parámetros del formulario normalmente lo que hacemos es apoyarnos de Java Vins

52
00:04:50,840 --> 00:04:57,440
para almacenar o procesar la información de lógica de negocio o lógica de presentación de nuestra aplicación

53
00:04:57,440 --> 00:05:02,200
web ya que hemos creado y almacenado la información en nuestros JavaBeans.

54
00:05:02,230 --> 00:05:09,370
Regresamos el control al servlet y este controlador puede colocar estos babys en algún alcance para

55
00:05:09,370 --> 00:05:12,790
compartir información hacia un JSP.

56
00:05:12,790 --> 00:05:16,850
Los alcances pueden ser request session o application.

57
00:05:17,020 --> 00:05:22,600
En este caso no aplica el alcance de Patch ya que los servlets no conocen este alcance.

58
00:05:22,600 --> 00:05:26,740
Este alcance de países únicamente aplica a los Gotha y Sepes.

59
00:05:26,800 --> 00:05:33,400
Por ello únicamente podemos manejar los tres alcances mencionados Rísquez sesión y aplicación.

60
00:05:33,520 --> 00:05:39,220
Una vez que el controlador ya ha colocado los JavaBeans en algún alcanze hace un redireccionamiento

61
00:05:39,220 --> 00:05:44,030
por medio del objeto Rikers despachen que vamos a ver más adelante.

62
00:05:44,230 --> 00:05:49,960
En este punto también cabe mencionar que al ser el controlador toma la decisión de cual TCP se va a

63
00:05:49,960 --> 00:05:51,070
utilizar.

64
00:05:51,070 --> 00:05:58,720
Por ejemplo podríamos tener un JSP 1 un gotee SP2 jote sp3 etcétera así que seleccionar cualquiera de

65
00:05:58,720 --> 00:06:05,230
estos JSP es va a depender del flujo de nuestra aplicación web pero en este caso el controlador es quien

66
00:06:05,230 --> 00:06:09,940
va a decidir cuál vista o TCP es el que se va a utilizar.

67
00:06:09,940 --> 00:06:16,510
Finalmente una vez que ya estamos dentro del JSP seleccionado lo que va a hacer el TCP es jugar el rol

68
00:06:16,510 --> 00:06:17,790
de la vista.

69
00:06:17,830 --> 00:06:23,440
Esto implica que únicamente va a recuperar la información que le ha compartido el servlet.

70
00:06:23,780 --> 00:06:27,700
Los CPC en teoría no deberían de crear nuevos objetos Java.

71
00:06:27,820 --> 00:06:34,180
Para ello toda la información que va a utilizar el JSP ya debió de haber sido procesada por el controlador

72
00:06:34,630 --> 00:06:41,320
una vez que el tcp genera el HTML utilizando la información de los JavaBeans que le proporcionó lo que

73
00:06:41,320 --> 00:06:47,410
hace es regresar el contenido al cliente y en este momento es cuando se genera el render o el envío

74
00:06:47,590 --> 00:06:48,690
de nuestra aplicación.

75
00:06:48,850 --> 00:06:55,450
Según el contentarme que hayamos utilizado por ejemplo puede ser una salida HTML pero también podríamos

76
00:06:55,450 --> 00:07:01,550
tener otro tipo de contenidos como documentos de tipo Excel PDF video audio etc..

77
00:07:01,630 --> 00:07:09,010
Según hemos visto en elecciones anteriores el punto es que el JSP únicamente va a desplegar la información

78
00:07:09,220 --> 00:07:13,580
que recibió del servlet y enviará esta información hacia el cliente.

79
00:07:13,810 --> 00:07:19,510
Con eso termina el flujo y si el cliente necesita realizar nuevamente otra petición entonces se repite

80
00:07:19,540 --> 00:07:25,600
todo el proceso nuevamente así que este diagrama es muy importante al cual pueden hacer referencia ya

81
00:07:25,600 --> 00:07:29,480
que es el que vamos a utilizar para implementar nuestro patrón de diseño MVC.

82
00:07:29,530 --> 00:07:32,110
Cuando trabajamos con JSP y concebibles

83
00:07:35,690 --> 00:07:40,030
pasos generales de un controlador vamos a comentar el código necesario.

84
00:07:40,040 --> 00:07:46,690
A grandes rasgos que utiliza un controlador según revisamos en la teoría de los servlets para procesar

85
00:07:46,720 --> 00:07:51,820
un parámetro podemos utilizar la notación Ricketts Punto G para meter.

86
00:07:51,820 --> 00:07:58,420
Así que en primer lugar si es que aplica procesamos y validamos los parámetros y utilizamos el objeto

87
00:07:58,420 --> 00:08:04,170
rico y el método G.T para meter indicando el nombre del parámetro que queremos recuperar.

88
00:08:04,210 --> 00:08:09,040
Posteriormente podemos validar los parámetros para saber si la información que estamos recibiendo es

89
00:08:09,040 --> 00:08:10,070
correcta.

90
00:08:10,210 --> 00:08:16,090
Una vez que hayamos procesado los parámetros podemos realizar la lógica de presentación respectiva.

91
00:08:16,100 --> 00:08:22,480
Una lógica de negocio utilizando babys el resultado de procesar esta información la vamos a almacenar

92
00:08:22,540 --> 00:08:24,410
en objetos de tipo Yavin.

93
00:08:24,580 --> 00:08:31,590
En este caso simplemente estamos creando un nuevo objeto de tipo rectángulo en este caso únicamente

94
00:08:31,590 --> 00:08:38,800
estamos creando un objeto de tipo rectángulo el cual es un Babín y estamos creando un nuevo Yavin para

95
00:08:38,800 --> 00:08:43,870
tratar de ejemplificar que estos bits van a tener la información de nuestra aplicación web

96
00:08:46,900 --> 00:08:52,510
posteriormente antes de redireccionar y seleccionar el JSP que vamos a utilizar debemos de compartir

97
00:08:52,570 --> 00:08:55,800
el objeto que estamos creando en algún alcance.

98
00:08:56,020 --> 00:09:01,480
En este caso estamos seleccionando el alcance de recuesto pero podemos utilizar los alcances de sección

99
00:09:01,570 --> 00:09:05,070
o aplicación para utilizar el alcance de aplicación.

100
00:09:05,110 --> 00:09:12,160
Vamos a utilizar el contexto de nuestro servlet en este caso vamos a utilizar el objeto Rísquez con

101
00:09:12,160 --> 00:09:18,370
el método set Atrium Biot e indicamos el nombre del alguien que se va a recuperar por parte del JSP

102
00:09:19,120 --> 00:09:24,610
así que en este caso estamos compartiendo un VIM llamado rectángulo Binh y esta información se va a

103
00:09:24,610 --> 00:09:30,640
almacenar también como si estuviéramos utilizando un mapa así que en este caso indicamos la llave y

104
00:09:30,640 --> 00:09:35,730
posteriormente separados por coma el valor así que tenemos la llave rectángulo Binh.

105
00:09:35,770 --> 00:09:41,560
Este es el nombre que va a utilizar el JSP para recuperar este Binh y este es el valor que le estamos

106
00:09:41,560 --> 00:09:50,120
asignando a esta llave así que de esta manera es como vamos a agregar atributos en cierto alcance finalmente

107
00:09:50,270 --> 00:09:56,810
seleccionamos el JSP que desplegará la información hacia el cliente por medio del código es despachar

108
00:09:57,140 --> 00:10:03,480
obtenemos el objeto de despachar y utilizamos el objeto Rísquez con el método guetto el cual despacharlo

109
00:10:03,830 --> 00:10:09,350
indicando cuál va a ser el JSP que vamos a utilizar para redireccionar la información hacia este JSP

110
00:10:10,100 --> 00:10:16,490
y finalmente por medio del objeto despachar hacemos un forward es decir que vamos a enviar la información

111
00:10:16,760 --> 00:10:18,270
hacia este JSP.

112
00:10:18,350 --> 00:10:25,010
Por ello es que vamos a reenviar los objetos recuas y responde a este JSP y de esta manera es que la

113
00:10:25,010 --> 00:10:31,970
información que hemos compartido en los alcances de Ricketts sesión o aplicación le va a llegar directamente

114
00:10:32,240 --> 00:10:40,070
al JSP llamado resultado punto JSP así que estos son los pasos generales que vamos a agregar en un controlador

115
00:10:40,670 --> 00:10:46,250
vamos a crear a continuación algunos ejercicios para poner en práctica el concepto del patrón de diseño

116
00:10:46,340 --> 00:10:47,120
MVC.

117
00:10:47,150 --> 00:10:49,550
Cuando trabajamos con JSP y servlets.