Exposición de la Arquitectura de MVP-VM

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

Introducción Java MVP-VM Framework

Hola,

Me gustaría empezar comentando la intención de este blog. Este blog surge de la necesidad de comentar e intercambiar opiniones sobre un framework que llevo desarrollando desde Septiembre del 2009.

Mi intención con este framework es dar respuesta a la creación de aplicaciones de escritorio, aunque lo estoy intentando dejar abierto para que pueda ser utilizado con aplicaciones web basadas en Java.

Tras una larga búsqueda de frameworks MVP, MVC, MVVM existentes para Java, la mayoría no dejaban de ser ideas o prototipos muy específicos para proyectos pequeños o medios o incluso buenos modelos teóricos pero sin una implementación palpable. No recuerdo ahora sus nombres, tendría que buscar, pero de tantos que encontré tengo una ensalada mental de todos ellos criminal. Entonces busqué por lo mismo pero en el dominio de .NET donde también abunda mucha documentación al respecto. Me documenté hasta que encontré el CAB (Composite Application Block) de Microsoft, esto es algo que estaba buscando, pero claro, lo que buscaba tendría que ser para Java; la idea del CAB es buena aunque alguno de sus conceptos no me convence, como el tener dentro de un workitem los modelos, vistas, controladores asociados a ese workitem, la razón del no convencimiento es por que bajo mi punto de vista, los modelos, vistas o controladores no deben estar vinculados directamente a algún workitem. Pero eso es otra historia... Aún así tiene ideas o conceptos que me gustan, como por ejemplo las smartParts.

En mi búsqueda también me orientó muchísimo la siguiente documentación,

• http://martinfowler.com/eaaDev/index.html
• http://www.jeremydmiller.com/ppatterns/Default.aspx?Page=MainPage&AspxAutoDetectCookieSupport=1
• http://codebetter.com/blogs/jeremy.miller/archive/2007/07/25/the-build-your-own-cab-series-table-of-contents.aspx
• http://breathingtech.com/2009/using-model-view-presenter-mvp-pattern-in-compact-framework/
• http://ooerabegins.wordpress.com/2009/05/29/hmvc-pattern1/
• http://blogs.msdn.com/dphill/archive/2009/01/31/the-viewmodel-pattern.aspx
• http://aviadezra.blogspot.com/2009/08/mvp-mvvm-winforms-data-binding.html
• http://aviadezra.blogspot.com/2008/06/mvpc-model-view-presenter-controller.html
• http://aviadezra.blogspot.com/2007/07/twisting-mvp-triad-say-hello-to-mvpc.html
• http://msdn.microsoft.com/en-us/library/dd490815.aspx
• http://www.paulstovell.com/wpf-model-view-presenter
• http://www.codeproject.com/KB/architecture/CABMDI.aspx?msg=2460122
• http://msdn.microsoft.com/es-es/architecture/default.aspx
• http://www.wintellect.com/CS/blogs/jlikness/archive/2010/04/14/model-view-viewmodel-mvvm-explained.aspx
• http://waf.codeplex.com/
• http://www.slideshare.net/lbugnion/understanding-the-mvvm-pattern-techdays-belgium
• http://www.slideshare.net/mattcasto/creating-applications-using-uhe-modelviewview-model-pattern
• http://www.global-webnet.net/blogengine/post/2010/02/05/MVPVM-Model-View-Presenter-View-Model-the-natural-evolution.aspx

Y de todo esto nace este framework que implementa el patrón MVP-VM y toda la infraestructura necesaria para que cualquiera que quiera desarrollar una aplicación bajo esta filosofía, sólo tenga que crear su modelo, su vista, su ViewModel y su presentador.

A excesivos grandes rasgos, asumo lo siguiente:

1. El Modelo es la información del problema resolver, lógica de negocio básicamente.
2. La Vista es el control de usuario visual
3. El ViewModel es la lógica de comportamiento de la vista
4. El Presentador es el encargado de pegar todas las piezas del puzzle MVP-VM.

En próximos artículos hablaré de ello en profundidad.

Actualmente la vista está implementada para utilizar Swing, aunque me gustaría en algún momento que pudiese funcionar con JavaFX "simplemente" con cambiar el interfaz de usuario.

Algunos os preguntaréis entonces porqué no utilicé algunas de las implementaciones existentes para el patrón MVP o VM, tengo varias respuestas para ello, algún quizás sean un tanto personales, otras sean más técnicas, otras son requisitos que no se cumplían...

1. No me gustó como abordaban el problema, redundando en la duplicación de código innecesasio.
2. Implementaciones muy básicas y simples que en algunos casos de uso que quiero llevar a cabo se quedaban cortos, por ejemplo la sincronización entre componentes visuales.
3. Necesidad de una implementación más flexible, de ahí hacer un modelo híbrido entre el Model-View-Presenter y el ViewModel.
4. El hacer esto me permite tener un mismo ViewModel (comportamiento de la vista) con diferentes implementaciones/representaciones de la vista, ya sean en swing, javafx u otro. En caso de ser una aplicación web quizás sería necesario definir un nuevo View Model o prescindir de el.
5. Posibilidad de reutilizar componentes en cualquier contexto.
6. Necesidad de definir widgets simples que pudiera integrar en un control de usuario más complejo, incluso definiendo una manera de comunicación entre estos widgets para que estos widgets simples puedan interactuar entre ellos en función de la interacción que el usuario haga con ellos.
7. Componentes básicos genéricos. Por ejemplo para mostrar una tabla de datos.
8. Carga dinámica de componentes.
9. Generación de automática de menús, barra de estado.
10. Servicio de login
11. Creo que me dejo alguna más pero ya no me acuerdo :D

Estoy pendiente de subir los fuentes de todas las versiones desde la primera hasta la actual con casos de ejemplo funcionales, documentación y pruebas de concepto a https://mvpvmframework.dev.java.net/ y https://sourceforge.net/projects/jmvpvmframework/

Espero vuestros comentarios al respecto, estoy dispuesto a críticas, ideas, mejoras, colaboraciones, lo que se os ocurra.

Un saludo y gracias por la lectura,

Raúl