En presente artículo presento una avanzadilla de la arquitectura que trataré de explicar para el desarrollo de aplicaciones bajo el framework basado en MVP-VM, al que denomino Afasia Framework. En posteriores artículos iré desmenuzando cada uno de los componentes lógicos de Afasia.
Afasia Framework pretende manejar todo lo referente a la definición de componentes de usuario, los mecanismos de comunicación entre componentes de usuario, proveer de un marco de aplicación para la utilización, diseño y ejecución de los componentes simples o compuestos, autenticación en el sistema, gestión de excepciones, sistema de trazas, composición de vistas, configuración de la aplicación y otros aspectos que seguro irán surgiendo a medida que todo este "invento" vaya evolucionando.
Para ello, Afasia Framework tiene que poder interactuar con los elementos (o componentes lógicos) de la aplicación pertenecientes a la capa de presentación y a la capa de negocio. La capa de acceso a datos y la capa de base de datos son indiferentes para Afasia desde el punto de vista de la interacción de Afasia hacia los DAO´s y hacia la base de datos. Quienes interaccionan con los elementos de estas capas serán el modelo del componente de usuario y la lógica de negocio. Bueno, sólo hay una excepción, hay un elemento que interacciona con la capa de acceso a datos, este elemento es el Gestor de conexiones que se encarga únicamente de devolver un conexión valida para el DAO, de esta manera tenemos todas las conexiones a la base de datos controladas.
Podréis preguntaros cómo encaja el MVP-VM dentro de toda esta arquitectura, la respuesta está en que el componente/vista de usuario es el que utiliza el patrón MVP-VM, a pesar de que sitúo al componente de usuario en la capa de presentación, aunque cuando veamos con lupa al componente de usuario observaremos que su vista (V), su presentador (P) y su ViewModel (VM) formarán parte de la capa de presentación y por otro lado el Modelo (M) formará parte de la capa de Negocio.
Este punto lo explicaré en los próximos artículos dónde quedará claro el porqué de esta tela de araña profundamente entremezclada, todo estriba en la perspectiva que utilicemos para enfocar la arquitectura. Procuraré también que esto quede reflejado de alguna manera en el diagrama de la arquitectura.
En el próximo artículo trataré el fundamento básico de este framework, la explicación de la implementación MVP-VM que llevé a cabo para poder definir los componentes de interfaz de usuario.
Hasta la siguiente artículo.
Un saludo,
Raúl
No hay comentarios:
Publicar un comentario