1 00:00:10,650 --> 00:00:13,350 Hola Te saludo nuevamente la costa. 2 00:00:13,950 --> 00:00:17,160 Espero que estén listos para comenzar con esta elección. 3 00:00:17,190 --> 00:00:24,010 A continuación vamos a estudiar el tema de capas de datos con Java JDBC están listos. 4 00:00:24,010 --> 00:00:33,490 Vamos buenas prácticas y patrones de diseño vamos a revisar a continuación el tema de las buenas prácticas 5 00:00:33,700 --> 00:00:39,790 y el concepto de patrones de diseño cuando estamos trabajando con Java en una arquitectura Java empresarial 6 00:00:40,060 --> 00:00:46,150 es común que la aplicación se divida en varias capas y cada una es responsable de realizar tareas en 7 00:00:46,150 --> 00:00:47,360 específico. 8 00:00:47,800 --> 00:00:53,320 Debido a la complejidad de los sistemas y los problemas a los que nos enfrentamos diariamente existe 9 00:00:53,320 --> 00:00:59,710 el concepto de buenas prácticas y también el concepto de patrones de diseño con el objetivo de reducir 10 00:00:59,830 --> 00:01:06,470 los problemas mencionados anteriormente las buenas prácticas incluyen temas de codificación división 11 00:01:06,470 --> 00:01:10,880 de responsabilidades en capas lógicas entre otros temas. 12 00:01:10,880 --> 00:01:16,820 A su vez los patrones de diseño como su nombre lo dice resuelven un problema que se presenta de manera 13 00:01:16,820 --> 00:01:25,060 recurrente es decir un patrón en el desarrollo de sistemas en particular en sistemas orientados a objetos. 14 00:01:25,370 --> 00:01:31,550 Un tema fundamental en el diseño de sistemas es el concepto de cohesión y acoplamiento. 15 00:01:31,550 --> 00:01:38,150 Este tema entra en juego cuando manejamos varias capas lógicas ya que cada capa es responsable de cierta 16 00:01:38,150 --> 00:01:41,810 funcionalidad como podemos observar en la figura. 17 00:01:41,900 --> 00:01:49,250 Tenemos la capa de presentación la capa de negocio y la capa de datos cada una de estas capas tiene 18 00:01:49,250 --> 00:01:55,940 ciertas responsabilidades por ejemplo la capa de presentación se encarga de administrar el flujo entre 19 00:01:55,940 --> 00:02:02,450 las distintas pantallas del sistema así como de procesar los datos del usuario es decir los formularios 20 00:02:02,900 --> 00:02:06,100 y desplegar la información al usuario. 21 00:02:06,110 --> 00:02:12,290 Por otro lado la capa de negocio se encarga de procesar la lógica de negocio y los servicios que debe 22 00:02:12,290 --> 00:02:14,630 manejar nuestro sistema. 23 00:02:14,660 --> 00:02:21,500 Por último la capa de datos es la encargada de la comunicación con la base de datos archivos entre otras 24 00:02:21,500 --> 00:02:23,640 fuentes de información. 25 00:02:23,690 --> 00:02:27,140 Las capas se intercomunicados para procesar la información. 26 00:02:27,200 --> 00:02:34,510 Esto es desde que un usuario hace una petición hasta que el sistema responde al usuario de nueva cuenta. 27 00:02:34,580 --> 00:02:43,740 A continuación vamos a describir algunas características de cada uno de estos temas cohesión y acoplamiento. 28 00:02:43,870 --> 00:02:50,050 Vamos a revisar a continuación el tema de cohesión y acoplamiento los cuales juegan un rol central en 29 00:02:50,050 --> 00:02:54,020 el diseño de software al diseñar nuestros módulos de software. 30 00:02:54,160 --> 00:03:00,190 Seguramente requeriremos de cambios posteriores conforme a las necesidades de la aplicación vayan cambiando 31 00:03:00,880 --> 00:03:06,610 por lo que el diseño de nuestro sistema puede impactar de manera directa en el tiempo y costo asociado 32 00:03:06,850 --> 00:03:08,950 para realizar dichos cambios. 33 00:03:08,980 --> 00:03:16,740 Por lo tanto vamos a revisar estos conceptos de cohesión y acoplamiento así que podemos resumir que 34 00:03:16,740 --> 00:03:20,490 el objetivo del diseño es minimizar costos de desarrollo 35 00:03:24,780 --> 00:03:30,900 la cohesión es la medida en la que un componente de software se dedica a realizar solamente una tarea 36 00:03:31,080 --> 00:03:38,800 para la cual fue creado delegando las tareas complementarias a otros componentes el acoplamiento por 37 00:03:38,800 --> 00:03:45,790 otro lado es la medida en que los cambios de un componente tienden a necesitar cambios de otro componente 38 00:03:46,540 --> 00:03:52,300 es decir que el acoplamiento mide el grado de dependencia entre dos o más elementos. 39 00:03:52,300 --> 00:03:59,520 Estos elementos pueden ser clases o cualquier otro tipo de componentes de software el objetivo del diseño 40 00:03:59,520 --> 00:04:05,440 de software es tener una alta cohesión y un bajo acoplamiento entre sus componentes. 41 00:04:05,730 --> 00:04:12,750 Así que estas son dos características que debemos tener en cuenta al momento de crear nuestras aplicaciones. 42 00:04:12,750 --> 00:04:19,290 La división en capas de manera lógica en una arquitectura empresarial introduce un bajo acoplamiento 43 00:04:19,560 --> 00:04:25,740 y una alta cohesión de manera automática debido a que permite que el número de relaciones entre cada 44 00:04:25,740 --> 00:04:30,800 capa sea el menor posible y aumente la cohesión en cada capa. 45 00:04:30,870 --> 00:04:39,560 Debido a que tenemos una división de responsabilidades de manera muy específica y clara ejemplo de alta 46 00:04:39,560 --> 00:04:47,650 cohesión en este ejemplo podemos observar el componente de impresión el cual únicamente tiene como responsabilidad 47 00:04:47,890 --> 00:04:54,550 imprimir cierta información para realizar las demás tareas se apoya en otros componentes por lo que 48 00:04:54,550 --> 00:05:01,060 se dice que tenemos una alta cohesión debido a que cada componente se dedica solo a realizar la tarea 49 00:05:01,240 --> 00:05:04,880 para la cual fue creado para lograr la alta cohesión. 50 00:05:04,900 --> 00:05:10,720 Nos vamos a apoyar de componentes como puede ser el componente de datos para obtener la información 51 00:05:10,720 --> 00:05:14,500 por ejemplo de alguna base de datos o algún archivo. 52 00:05:14,500 --> 00:05:20,710 También nos vamos a apoyar del componente para presentar la información y un componente para dar formato 53 00:05:20,770 --> 00:05:28,380 a la información que seleccione el usuario el componente de impresión en el diseño de clases no es necesariamente 54 00:05:28,440 --> 00:05:35,310 el diseño más importante ya que podemos observar que al imprimir no necesariamente debemos tener todas 55 00:05:35,310 --> 00:05:42,240 las tareas siendo ejecutadas por este componente sino que podemos apoyarnos de más componentes para 56 00:05:42,240 --> 00:05:45,650 realizar finalmente la tarea de impresión. 57 00:05:45,660 --> 00:05:52,020 Algunos de estos componentes incluso pueden ser parte de otras aplicaciones y podemos reutilizar código 58 00:05:52,260 --> 00:05:58,470 y componentes de otras aplicaciones siempre y cuando los componentes tengan pocas dependencias y el 59 00:05:58,470 --> 00:06:06,080 código haya sido diseñado teniendo en cuenta una alta cohesión este tipo de diseños permite que los 60 00:06:06,080 --> 00:06:13,640 cambios sean más fáciles de identificar y de realizar pero genera componentes más pequeños es decir 61 00:06:13,760 --> 00:06:19,460 con menos código lo cual podría incrementar el acoplamiento y según comentamos. 62 00:06:19,460 --> 00:06:26,300 Esto no es deseable para corregir esto se debe de manejar un balance entre el diseño de componentes 63 00:06:26,540 --> 00:06:30,260 y tratar de que no sean módulos demasiado pequeños. 64 00:06:30,260 --> 00:06:36,890 También debemos de tener cuidado en que los componentes no sean demasiado grandes es decir que no tengan 65 00:06:36,980 --> 00:06:40,820 demasiado código o demasiadas responsabilidades. 66 00:06:40,880 --> 00:06:46,250 De lo contrario los errores van a ser cada vez más difíciles de resolver y de identificar 67 00:06:48,540 --> 00:06:56,310 ejemplo de bajo acoplamiento como podemos observar en la figura estamos mostrando componentes que presentan 68 00:06:56,370 --> 00:07:01,050 un flujo para la extracción de información con una base de datos. 69 00:07:01,260 --> 00:07:07,470 Podemos observar el menor número de relaciones posibles ya que estamos evitando la comunicación directa 70 00:07:07,770 --> 00:07:14,610 entre la capa de servicio y la capa que crea la conexión a la base de datos es decir que estamos obteniendo 71 00:07:14,820 --> 00:07:16,380 un bajo acoplamiento. 72 00:07:16,680 --> 00:07:21,550 Así que la relación entre el componente de datos y la conexión a la base de datos. 73 00:07:21,660 --> 00:07:28,560 Esta relación sí es necesaria y podemos manejarla entre nuestros componentes pero si tuviéramos una 74 00:07:28,560 --> 00:07:35,670 relación entre el componente de servicio y la conexión a la base de datos estaríamos generando más relaciones 75 00:07:35,730 --> 00:07:42,180 de las necesarias y por lo tanto generaremos mayor dependencia entre cada uno de los componentes. 76 00:07:42,660 --> 00:07:46,770 Así que esta relación en la medida de lo posible debemos evitarla. 77 00:07:46,860 --> 00:07:54,940 Esto para generar la menor cantidad de dependencias posibles y obtener un bajo acoplamiento pero podemos 78 00:07:54,940 --> 00:08:01,300 observar que la relación entre el componente de servicio y el componente de datos sí es necesaria así 79 00:08:01,300 --> 00:08:07,300 que esta relación sí la podemos mantener y podemos considerar que tenemos el menor número de relaciones 80 00:08:07,540 --> 00:08:10,680 manejando el concepto de bajo acoplamiento. 81 00:08:10,810 --> 00:08:16,450 Uno de los objetivos del diseño de software es hacer los componentes reutilizables por lo que entre 82 00:08:16,450 --> 00:08:23,050 mayor dependencia exista entre cada componente más difícil va a ser tomar un módulo y adecuarlo para 83 00:08:23,070 --> 00:08:25,750 reutilizarlo en otra aplicación. 84 00:08:25,750 --> 00:08:32,200 Por ello es muy importante manejar estos dos conceptos en balance tanto el concepto de alta cohesión 85 00:08:32,440 --> 00:08:35,470 y en conjunto con el concepto de bajo acoplamiento 86 00:08:38,040 --> 00:08:39,740 patrones de diseño. 87 00:08:39,960 --> 00:08:46,620 Vamos a revisar ahora el tema de patrones de diseño un patrón de diseño es una guía que puede involucrar 88 00:08:46,620 --> 00:08:52,440 a varias clases y que a su vez nos permite resolver un problema que se presenta de manera repetitiva 89 00:08:53,670 --> 00:08:59,580 cuando hablamos de las capas de una arquitectura empresarial en este caso la capa de presentación la 90 00:08:59,580 --> 00:09:06,120 capa de servicio y la capa de acceso a datos cada capa puede tener varios patrones de diseño. 91 00:09:06,180 --> 00:09:12,510 Por ejemplo en la capa de presentación podemos observar los patrones de diseño como es el patrón MVC. 92 00:09:12,510 --> 00:09:19,920 Este patrón significa modelo vista controlador o en inglés Model View Controller y su objetivo es dividir 93 00:09:19,920 --> 00:09:23,020 las responsabilidades entre estos tres rubros. 94 00:09:23,190 --> 00:09:30,650 Un modelo una vista y un controlador también tenemos el patrón Front Controller el cual nos permite 95 00:09:30,650 --> 00:09:37,550 proporcionar una entrada única a nuestra aplicación cuando el usuario hace una petición y por lo tanto 96 00:09:37,580 --> 00:09:44,330 aquí podemos aplicar varias características como puede ser algún tipo de seguridad validaciones entre 97 00:09:44,330 --> 00:09:45,870 otro tipo de conceptos. 98 00:09:46,100 --> 00:09:54,380 El patrón DTO el cual significa data transfer Object representa un objeto del dominio del problema. 99 00:09:54,380 --> 00:10:01,810 En ocasiones puede ser una clase de entidad esto es una clase que se persiste en una base de datos. 100 00:10:02,030 --> 00:10:06,990 Esto es una clase que se persiste o guarda en una base de datos. 101 00:10:07,010 --> 00:10:09,680 Este patrón aparece entre las tres capas. 102 00:10:09,680 --> 00:10:16,130 Como podemos observar debido a que se utiliza para transferir una entidad o una lista de entidades de 103 00:10:16,130 --> 00:10:20,370 cierto tipo entre las distintas capas de la aplicación. 104 00:10:20,570 --> 00:10:27,410 Por ejemplo un usuario puede estar solicitando un listado de personas entonces la capa de presentación 105 00:10:27,590 --> 00:10:33,980 procesa la petición y solicita posteriormente a la capa de servicio que ejecute el método. 106 00:10:33,980 --> 00:10:36,050 Encontrar el listado de personas. 107 00:10:36,800 --> 00:10:42,680 Posteriormente la capa de servicio accede a la capa de datos para que podamos recuperar el listado de 108 00:10:42,680 --> 00:10:49,670 personas y posteriormente vamos a regresar un listado de objetos de persona utilizando estos objetos 109 00:10:49,730 --> 00:10:52,220 DTO el objeto dto. 110 00:10:52,250 --> 00:10:59,150 En este caso es un objeto de tipo Persona y entonces comenzamos a regresar la información hasta que 111 00:10:59,150 --> 00:11:06,630 damos una respuesta al usuario con el listado de personas que ha solicitado en la capa de negocio tenemos 112 00:11:06,630 --> 00:11:13,830 varios patrones como puede ser por ejemplo el patrón bisnes de la OIT el cual se encarga de los detalles 113 00:11:13,980 --> 00:11:21,390 de llamar a algún método de servicio y a su vez también tenemos el patrón servis por el cual es utilizado 114 00:11:21,390 --> 00:11:27,450 por el patrón bisnes delegas para localizar los servicios si es que se encuentra en algún directorio 115 00:11:27,750 --> 00:11:31,230 como puede ser algún directorio de tipo Ojota Ndi. 116 00:11:31,290 --> 00:11:38,160 Esto significa ya van aiming and Directory Interface y es una pide IAVA para ubicar un directorio de 117 00:11:38,160 --> 00:11:39,370 servicios. 118 00:11:39,420 --> 00:11:45,780 De momento solo es importante saber que existe una separación de responsabilidades en cada una de las 119 00:11:45,780 --> 00:11:55,080 capas de una aplicación Java empresarial por último en la capa de datos tenemos el patrón dado qué significa. 120 00:11:55,080 --> 00:12:02,970 Data Access obvie este patrón se encarga de extraer y almacenar información en la base de datos y este 121 00:12:02,970 --> 00:12:06,840 es uno de los patrones que utilizaremos en este curso. 122 00:12:06,840 --> 00:12:12,630 Cabe mencionar que existe un catálogo extenso de patrones de diseño para aullaba por lo que estos son 123 00:12:12,630 --> 00:12:19,630 solamente algunos de los patrones de diseño que se pueden utilizar pero existen muchos más las tres 124 00:12:19,630 --> 00:12:25,150 capas que estamos mostrando son las más comunes que se utilizan en el desarrollo de aplicaciones Java 125 00:12:26,050 --> 00:12:30,340 pero no son las únicas e incluso podemos tener menos capas. 126 00:12:30,340 --> 00:12:36,370 En ocasiones únicamente tenemos una capa de presentación que se comunica directamente con la base de 127 00:12:36,370 --> 00:12:37,450 datos. 128 00:12:37,450 --> 00:12:44,790 Aunque este tipo de prácticas no son recomendables a menos que sean prototipos el tipo de arquitectura 129 00:12:44,790 --> 00:12:51,780 final dependerá realmente del problema que queremos resolver pero nuestra recomendación es que utilicemos 130 00:12:51,780 --> 00:12:58,110 como mínimo estas tres capas para que los cambios y el mantenimiento de nuestros sistemas sean mucho 131 00:12:58,110 --> 00:12:59,750 más sencillos de realizar. 132 00:13:01,110 --> 00:13:07,220 A continuación vamos a crear un ejercicio para crear una capa de datos utilizando el API de JDBC.