Hola Te saludo nuevamente la costa.
Espero que estén listos para comenzar con esta elección.
A continuación vamos a estudiar el tema de capas de datos con Java JDBC están listos.
Vamos buenas prácticas y patrones de diseño vamos a revisar a continuación el tema de las buenas prácticas
y el concepto de patrones de diseño cuando estamos trabajando con Java en una arquitectura Java empresarial
es común que la aplicación se divida en varias capas y cada una es responsable de realizar tareas en
específico.
Debido a la complejidad de los sistemas y los problemas a los que nos enfrentamos diariamente existe
el concepto de buenas prácticas y también el concepto de patrones de diseño con el objetivo de reducir
los problemas mencionados anteriormente las buenas prácticas incluyen temas de codificación división
de responsabilidades en capas lógicas entre otros temas.
A su vez los patrones de diseño como su nombre lo dice resuelven un problema que se presenta de manera
recurrente es decir un patrón en el desarrollo de sistemas en particular en sistemas orientados a objetos.
Un tema fundamental en el diseño de sistemas es el concepto de cohesión y acoplamiento.
Este tema entra en juego cuando manejamos varias capas lógicas ya que cada capa es responsable de cierta
funcionalidad como podemos observar en la figura.
Tenemos la capa de presentación la capa de negocio y la capa de datos cada una de estas capas tiene
ciertas responsabilidades por ejemplo la capa de presentación se encarga de administrar el flujo entre
las distintas pantallas del sistema así como de procesar los datos del usuario es decir los formularios
y desplegar la información al usuario.
Por otro lado la capa de negocio se encarga de procesar la lógica de negocio y los servicios que debe
manejar nuestro sistema.
Por último la capa de datos es la encargada de la comunicación con la base de datos archivos entre otras
fuentes de información.
Las capas se intercomunicados para procesar la información.
Esto es desde que un usuario hace una petición hasta que el sistema responde al usuario de nueva cuenta.
A continuación vamos a describir algunas características de cada uno de estos temas cohesión y acoplamiento.
Vamos a revisar a continuación el tema de cohesión y acoplamiento los cuales juegan un rol central en
el diseño de software al diseñar nuestros módulos de software.
Seguramente requeriremos de cambios posteriores conforme a las necesidades de la aplicación vayan cambiando
por lo que el diseño de nuestro sistema puede impactar de manera directa en el tiempo y costo asociado
para realizar dichos cambios.
Por lo tanto vamos a revisar estos conceptos de cohesión y acoplamiento así que podemos resumir que
el objetivo del diseño es minimizar costos de desarrollo
la cohesión es la medida en la que un componente de software se dedica a realizar solamente una tarea
para la cual fue creado delegando las tareas complementarias a otros componentes el acoplamiento por
otro lado es la medida en que los cambios de un componente tienden a necesitar cambios de otro componente
es decir que el acoplamiento mide el grado de dependencia entre dos o más elementos.
Estos elementos pueden ser clases o cualquier otro tipo de componentes de software el objetivo del diseño
de software es tener una alta cohesión y un bajo acoplamiento entre sus componentes.
Así que estas son dos características que debemos tener en cuenta al momento de crear nuestras aplicaciones.
La división en capas de manera lógica en una arquitectura empresarial introduce un bajo acoplamiento
y una alta cohesión de manera automática debido a que permite que el número de relaciones entre cada
capa sea el menor posible y aumente la cohesión en cada capa.
Debido a que tenemos una división de responsabilidades de manera muy específica y clara ejemplo de alta
cohesión en este ejemplo podemos observar el componente de impresión el cual únicamente tiene como responsabilidad
imprimir cierta información para realizar las demás tareas se apoya en otros componentes por lo que
se dice que tenemos una alta cohesión debido a que cada componente se dedica solo a realizar la tarea
para la cual fue creado para lograr la alta cohesión.
Nos vamos a apoyar de componentes como puede ser el componente de datos para obtener la información
por ejemplo de alguna base de datos o algún archivo.
También nos vamos a apoyar del componente para presentar la información y un componente para dar formato
a la información que seleccione el usuario el componente de impresión en el diseño de clases no es necesariamente
el diseño más importante ya que podemos observar que al imprimir no necesariamente debemos tener todas
las tareas siendo ejecutadas por este componente sino que podemos apoyarnos de más componentes para
realizar finalmente la tarea de impresión.
Algunos de estos componentes incluso pueden ser parte de otras aplicaciones y podemos reutilizar código
y componentes de otras aplicaciones siempre y cuando los componentes tengan pocas dependencias y el
código haya sido diseñado teniendo en cuenta una alta cohesión este tipo de diseños permite que los
cambios sean más fáciles de identificar y de realizar pero genera componentes más pequeños es decir
con menos código lo cual podría incrementar el acoplamiento y según comentamos.
Esto no es deseable para corregir esto se debe de manejar un balance entre el diseño de componentes
y tratar de que no sean módulos demasiado pequeños.
También debemos de tener cuidado en que los componentes no sean demasiado grandes es decir que no tengan
demasiado código o demasiadas responsabilidades.
De lo contrario los errores van a ser cada vez más difíciles de resolver y de identificar
ejemplo de bajo acoplamiento como podemos observar en la figura estamos mostrando componentes que presentan
un flujo para la extracción de información con una base de datos.
Podemos observar el menor número de relaciones posibles ya que estamos evitando la comunicación directa
entre la capa de servicio y la capa que crea la conexión a la base de datos es decir que estamos obteniendo
un bajo acoplamiento.
Así que la relación entre el componente de datos y la conexión a la base de datos.
Esta relación sí es necesaria y podemos manejarla entre nuestros componentes pero si tuviéramos una
relación entre el componente de servicio y la conexión a la base de datos estaríamos generando más relaciones
de las necesarias y por lo tanto generaremos mayor dependencia entre cada uno de los componentes.
Así que esta relación en la medida de lo posible debemos evitarla.
Esto para generar la menor cantidad de dependencias posibles y obtener un bajo acoplamiento pero podemos
observar que la relación entre el componente de servicio y el componente de datos sí es necesaria así
que esta relación sí la podemos mantener y podemos considerar que tenemos el menor número de relaciones
manejando el concepto de bajo acoplamiento.
Uno de los objetivos del diseño de software es hacer los componentes reutilizables por lo que entre
mayor dependencia exista entre cada componente más difícil va a ser tomar un módulo y adecuarlo para
reutilizarlo en otra aplicación.
Por ello es muy importante manejar estos dos conceptos en balance tanto el concepto de alta cohesión
y en conjunto con el concepto de bajo acoplamiento
patrones de diseño.
Vamos a revisar ahora el tema de patrones de diseño un patrón de diseño es una guía que puede involucrar
a varias clases y que a su vez nos permite resolver un problema que se presenta de manera repetitiva
cuando hablamos de las capas de una arquitectura empresarial en este caso la capa de presentación la
capa de servicio y la capa de acceso a datos cada capa puede tener varios patrones de diseño.
Por ejemplo en la capa de presentación podemos observar los patrones de diseño como es el patrón MVC.
Este patrón significa modelo vista controlador o en inglés Model View Controller y su objetivo es dividir
las responsabilidades entre estos tres rubros.
Un modelo una vista y un controlador también tenemos el patrón Front Controller el cual nos permite
proporcionar una entrada única a nuestra aplicación cuando el usuario hace una petición y por lo tanto
aquí podemos aplicar varias características como puede ser algún tipo de seguridad validaciones entre
otro tipo de conceptos.
El patrón DTO el cual significa data transfer Object representa un objeto del dominio del problema.
En ocasiones puede ser una clase de entidad esto es una clase que se persiste en una base de datos.
Esto es una clase que se persiste o guarda en una base de datos.
Este patrón aparece entre las tres capas.
Como podemos observar debido a que se utiliza para transferir una entidad o una lista de entidades de
cierto tipo entre las distintas capas de la aplicación.
Por ejemplo un usuario puede estar solicitando un listado de personas entonces la capa de presentación
procesa la petición y solicita posteriormente a la capa de servicio que ejecute el método.
Encontrar el listado de personas.
Posteriormente la capa de servicio accede a la capa de datos para que podamos recuperar el listado de
personas y posteriormente vamos a regresar un listado de objetos de persona utilizando estos objetos
DTO el objeto dto.
En este caso es un objeto de tipo Persona y entonces comenzamos a regresar la información hasta que
damos una respuesta al usuario con el listado de personas que ha solicitado en la capa de negocio tenemos
varios patrones como puede ser por ejemplo el patrón bisnes de la OIT el cual se encarga de los detalles
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
por el patrón bisnes delegas para localizar los servicios si es que se encuentra en algún directorio
como puede ser algún directorio de tipo Ojota Ndi.
Esto significa ya van aiming and Directory Interface y es una pide IAVA para ubicar un directorio de
servicios.
De momento solo es importante saber que existe una separación de responsabilidades en cada una de las
capas de una aplicación Java empresarial por último en la capa de datos tenemos el patrón dado qué significa.
Data Access obvie este patrón se encarga de extraer y almacenar información en la base de datos y este
es uno de los patrones que utilizaremos en este curso.
Cabe mencionar que existe un catálogo extenso de patrones de diseño para aullaba por lo que estos son
solamente algunos de los patrones de diseño que se pueden utilizar pero existen muchos más las tres
capas que estamos mostrando son las más comunes que se utilizan en el desarrollo de aplicaciones Java
pero no son las únicas e incluso podemos tener menos capas.
En ocasiones únicamente tenemos una capa de presentación que se comunica directamente con la base de
datos.
Aunque este tipo de prácticas no son recomendables a menos que sean prototipos el tipo de arquitectura
final dependerá realmente del problema que queremos resolver pero nuestra recomendación es que utilicemos
como mínimo estas tres capas para que los cambios y el mantenimiento de nuestros sistemas sean mucho
más sencillos de realizar.
A continuación vamos a crear un ejercicio para crear una capa de datos utilizando el API de JDBC.