Clase 26 - Arquitectura de capas

Vista previa del material en texto

Clase 26 - Arquitectura de capas
Arquitectura por capas
¿Qué es una arquitectura de capas?
Es un patrón de diseño donde los módulos contemplados dentro de nuestro aplicativo son separados por “capas”
¿Pero qué implica una “capa”?
El nombre “capa” hace referencia a cada rol que debe cumplirse dentro de todo el aplicativo.
Por ejemplo:
Contamos con ciertos archivos que tienen la labor de mostrar vistas: ¿Por qué estos archivos tendrían que hacer otro cálculo más allá de renderizar una vista?
Responsabilidades
Cuando trabajamos con capas, entendemos que cada archivo debe cumplir una función específica, permitiendo así que, si llegase a ocurrir algún “error” o si llegase a requerirse modificación en algún punto, tengamos más claro dónde debemos atacar esos cambios
Capas base
Capas base
En un sistema que trabaje con este modelo, es necesario contar con tres capas base:
· Capa de Modelo o Persistencia
· Capa de Controlador o Negocio
· Capa de Vista o Renderización.
Sin estas tres capas, el modelo se volvería inconsistente y la comunicación entre los módulos sería débil y generaría muchos problemas.
Capa de Persistencia
Esta capa tiene por principal objetivo la conexión directa con el modelo de persistencia a trabajar, es decir, debe saber conectar con la persistencia en memoria, en archivos o en bases de datos, todo dependendiendo de cómo haya sido programada la capa
La capa de persistencia no debería realizar validaciones ni operaciones más allá del CRUD que corresponde a una capa de persistencia.
Para modelos más complejos como Persistencias en bases de datos, también es posible configurar operaciones transaccionales y Agregaciones en este mismo punto. 
Capa de Negocio
Esta capa tiene como fin el desarrollar la lógica correspondiente a la acción de la función. Es decir, debe realizar todas las operaciones necesarias para que la operación esté finalizada.
Negocio usualmente necesita de las otras capas para poder resolver la tarea solicitada.
Negocio no puede acceder ni modificar directamente a los datos, sino que tiene que hacerlo a partir de la utilización de Persistencia.
Por lo tanto, Negocio suele tener una instancia de Persistencia para poder utilizarla. 
Capa de Renderizado
La capa de renderizado o Vista, como indica su nombre, sólo tiene la función de tomar datos para poder ser renderizados.
Esta capa es una de las más subjetivas en la arquitectura, pues si bien TODOS los modelos requieren renderizar contenido, se hace de maneras muy diferentes
Renderizado, según sea el enfoque del equipo, también puede acceder a Persistencia sin necesidad de pasar por negocio, siempre y cuando ésta tenga como fin único el de mostrar la información correspondiente. 
En ocasiones, también se suele contemplar la capa de renderizado fuera de la arquitectura interna y usar algún aplicativo externo (como enviar la info a React para que él la renderice, que es lo más habitual)
¿Has notado tus componentes?
¿Te has dado cuenta de que, la capa que corresponde al renderizado en tu página, no conecta de manera tan consistente con las demás capas de tu aplicativo? 
Es decir, contamos con capas que acceden a persistencia, contamos con capas que Estos modelos son habitualmente utilizados cuando se trata de manejar un sistema “simple” de sitios web sin tanta complejidad. Ya que, si tuviéramos modelos más complejos, sí necesitaríamos retirar nuestras vistas internas y proceder a utilizar los renderizados con un front externo.
Muchas aplicaciones web que encontrarás más adelante, se regirán bajo este segundo modelo (front externo), por lo que debemos hacer énfasis en cómo separar de una manera ligeramente diferente las cosas en nodejs
Capas adicionales para node js
Capa de routing
La capa de routing contendrá todos los archivos de tipo “router” que, como estamos ya acostumbrados, es una capa basada en redireccionamientos hacia puntos específicos de nuestra API
Actualmente, con el uso de motores de plantillas, nuestra capa de routing está estrechamente conectada con la capa de renderización (al utilizar un views router)
Sin esta capa, todas nuestras rutas de todas nuestras entidades se encontrarían en un mismo archivo, complicando la lectura del código posteriormente.
Capa de servicio
La capa de servicios es una capa intermedia entre el controlador y la persistencia, en esencia, un servicio tiene la capacidad de servir como “tunel” de conexión, para que el controlador pueda acceder de manera más homologada a la persistencia.
Contar con una capa de servicio impide que los accesos a persistencia se hagan descontroladamente, con argumentos erróneos, etc.
Además, son el punto clave para aplicar un patrón repository.
No confundir una capa de servicio con la capa de negocio, solo es un punto intermedio de conexión.
Analizando el flujo de arquitectura
Echemos un vistazo con mayor detenimiento al flujo
Vamos a realizar un repaso sobre cómo deben estar interactuando las capas del proyecto recién desarrollado, atendiendo a comprender el por qué es que están realizando esa tarea
Para ello, se enunciará la información desde el momento en el que el cliente realiza una consulta al servidor, hasta el momento en el que se resuelve la información y envía como respuesta.
Inicio: capa de vista, presentación o renderizado
Como es de esperarse, todo comienza desde el cliente, cuando este carga una página, aprieta un botón o desea buscar un dato, está haciendo una petición al servidor.
Para ello, desde esta capa se hace un “consumo”, el cual hará una operación de solicitud para obtener los datos.
Primer contacto: capa ruteo
La petición tuvo que realizarse a partir de un endpoint, el cual entra a la capa de ruteo y designa cuál de todas las rutas corresponden a la acción que desea realizar el cliente.
Segundo contacto: Capa de controlador
Cada ruta está relacionada con algún método o función de un controlador, así, cuando el router reconoce adónde está apuntando el cliente, sabe llevarlo a la función adecuada. (En esta explicación, el usuario quiere obtener los usuarios)
Tercer contacto: Capa de Servicio
Para poder obtener los usuarios, la función getUsers requerirá acceder al userService, que es el punto intermedio entre el controlador y entre la capa de persistencia.
Cuarto contacto: capa de Persistencia.
El servicio de usuarios sabe que debe acceder a usuarios, el detalle es ¿de qué persistencia? ¿Memoria, archivos, base de datos? el servicio sabrá a qué persistencia conectar y obtendrá los datos
Regreso: vuelta de datos y envío al cliente.
Una vez obtenidos los datos a partir de la persistencia, el controlador termina de procesarlos y puede finalmente enviarlos al cliente para terminar el procesamiento de esa petición.