Implementando el patrón MVVM con ZK. II

En la entrada anterior  habíamos creado un proyecto Maven de ZK y mostrábamos el patrón MVVM a través de sus características y ventajas y dijimos que íbamos a implementar nuevamente un ejemplo que ya teníamos en MVC pero ahora usando el patrón MVVM.

Para realizar esto partimos del proyecto inicialmente creado, como pueden ver a continuación.

Como estaremos reutilizando mucho código copiaremos tanto las vistas como los modelos implementados usando spring + hibernate. Y lo que realizaremos será cambiar el controlador por un viewmodel que nos enlace todo.

Llegado este momento ya se han copiado los paquetes de los dao, modelo y servicios y el proyecto se puede ver como sigue:

Claro también se han resuelto los temas de las dependencias de spring e hibernate que tienen las clases importadas incluyendo las dependencias en el fichero pom.xml.

La clase MyViewModel la pueden ver a continuación:

Y es sobre la que estaremos trabajando para implementar el MVVM.

Recordemos la UI de este ejemplo:

Vean que se permiten las operaciones CRUD básicas sobre los datos de una persona.

Lo primero es ver la definición de los atributos de la clase viewmodel:

Como se puede apreciar creo variables para cada atributo de la persona que voy a gestionar en la UI.

Luego como sé que debo mostrar un listado de las personas, creo otro atributo para este fin.

Como permitiré que se seleccione un elemento del listado, creo un atributo current de tipo Persona.

Y por último creo un atributo vacío para mostrar un label con información de si algún campo está vacío o no.

Veamos entonces como en la UI capturo los datos de un usuario:

Lo primero es que vean como window usa el BindComposer y se le asocia el viewmodel que se ha implementado.

Resaltado aparece la sección de código que nos interesa, vean como se dice que el valor del textbox nombre será @bind(vm.current.nombre). O sea estoy diciendo que todo lo que escriba ahí será guardado en una instancia del current.nombre que definí en el viewmodel y lo mismo para los otros atributos.

Si recuerdan que en la entrada anterior decíamos que las acciones sobre la vista se mapearían con métodos Command en el viewmodel, en el código se puede ver así:

De esta manera cuando quiera hacer un Adicionar en el viewmodel solo tengo que implementar lo siguiente:

Vean como anoto el método con @Command y luego con @NotifyChange.

Eso se debe a que este método se mapea con un comando que genera la UI y que cuando se ejecute debe actualizar los elementos “listPersona”, “current” y “vacio” en la UI.

Veamos quien es listPersona:

Como ven el listbox que uso para mostrar el listado de las personas recibe sus datos del modelo vm.listPersonas, es por eso que cada vez que añado una nueva persona notifico para que se actualice. El mecanismo de actualización se realiza a través de los get/set de cada elemento que están definidos en el viewmodel.

Aquí también pueden ver como capturo cada elemento del listado devuelto de la siguiente forma: each.atributo.

Lo otro que pueden observar es que defino el elemento selectedItem, esto implica que cuando pincho sobre un elemento de la lista los valores de ese elemento son añadidos al elemento vm.current y por lo tanto mostrados en el grid del inicio. Esto se hace por si se desea modificar o eliminar alguno de los elementos del listado.

Realmente la mayor diferencia entre MVVM y MVC está en el control que se tiene sobre los diferentes elementos de la UI del framework ZK, y claro las ventajas listadas en la entrada anterior.

Les dejo adjunto  el código fuente para que hagan sus pruebas.

 

---

{ Leer Más }

Implementando el patrón MVVM con ZK. I

En esta entrada veremos cómo crear un proyecto de ZK con Maven y comenzaremos la introducción del patrón MVVM para luego en otra entrada mostrar cómo implementar una aplicación web de ejemplo con ZK usando el patrón MVVM (Model View View-Model).

Lo primero es crearnos una aplicación en el Eclipse STS, ustedes pueden usar otra variante del IDE siempre que tengan un plugin de Maven instalado.

En el STS seguimos estos pasos descritos en el sitio de ZK para poder añadir un arquetipo de Maven a nuestro IDE.

Luego creamos un proyecto Maven.

Y seleccionamos el id del arquetipo a usar:

Seleccionamos el arquetipo y damos Next.

Damos finish y listo. Ya tenemos el proyecto creado. Vean su estructura.

Como ven nos ha creado ya una primera clase, nos ha descargado todas las dependencias necesarias para el trabajo con ZK y nos ha creado una página index.zul sobre la cual podemos empezar a trabajar.

Para acelerar el trabajo se usará el mismo ejemplo que ya desarrollamos en ZK para el patrón MVC y lo llevaremos entonces a MVVM en la siguiente entrada.

Explicamos a continuación las características de este patrón que luego se verán a nivel de código en la siguiente entrada de esta serie:

1. MVVM es un patrón que se originó en Microsoft y constituye una especialización del patrón “Presentation Model” creado por Martin Fowler como una variante del patrón MVC. Este patrón tiene 3 roles: View, Model y ViewModel.

2. La vista y el modelo juegan el mismo rol que en el patrón MVC, mientras que el elemento ViewModel se puede considerar como una especialización de un Controlador, donde puede extraer información de una o más clases modelos para ser mostradas en las vistas. Esta información es expuesta a través de métodos get/set como propiedades JavaBeans.

3. Se dice que el ViewModel es un modelo de una vista, aunque esto hay que explicarlo bien porque aunque contiene el estado de las vistas asociadas no contiene ninguna referencia a los componentes de una vista, por lo que no puede acceder a ella directamente.

4. La restricción del punto 3 impone la existencia de un mecanismo que sincronice la información entre vistas y viewmodel, y es llamado databinding. Una vez que el desarrollador establece este mecanismo, el mismo se encarga de mantener la información sincronizada entre ambos elementos como se puede apreciar en la siguiente imagen.

5. Se dice también que los viewmodel actual como controladores en MVC. Ya que el mecanismo databinding reenvía eventos a manejadores en el viewmodel. Estos manejadores son métodos con anotaciones java específicas. Estos métodos no son otra cosa que patrones Command, los cuales se encargan de manipular datos y notificar a través de los databinding de cambios en los datos, como se aprecia en esta imagen.

6. Los elementos viewmodel pueden ser clases POJO, y no conocer nada de las vistas que son usadas para enviarle eventos y mostrar los datos, lo que aumenta su reutilización.

7. Como los mecanismos de databinding son los encargados de mantener una sincronización entre las vistas y los viewmodel los desarrolladores tienen que especificar los comandos y las dependencias de datos en los viewmodel lo cual se hace usando anotaciones. Un ejemplo de estas anotaciones se puede mostrar en la siguiente imagen.

Como pueden ver se ha definido un atributo de la clase con sus métodos get/set y un método anotado como @Command y con @NotifyChange para indicar los elementos a notificar.

8. La forma de enlazar un viewmodel desde una vista es la siguiente:

Lo importante es ver como al componente Windows se le aplica el binder org.zkoss.bind.BindComposer el que permite instanciar el viewmodel foo.MyViewModel identificándolo a partir de ese momento con el id = vm.

Luego pueden ver que se accede a los atributos del viewmodel usando esta sintaxis @bind(vm.name) y a los métodos usando @command('newOrder')

Las ventajas de este patrón son las siguientes:

· Encaja muy bien cuando se desea que los equipos de diseño de las vistas y de los viewmodel trabajen en paralelo. Solo se debe definir el contrato respecto a la información a intercambiar y listo. Cada uno trabaja por su parte.

· Presenta un bajo acoplamiento con la lista, ya que los viewmodel no conocen nada acerca de la vista con la cual son enlazados.

· Se mejora mucho la reusabilidad, al poder usarse un mismo viewmodel para diferentes vistas.

· Se mejora la prueba del sistema, si se quiere usar un método guiado por pruebas. Esto se debe a que al no existir una dependencia respecto a las vistas, los viewmodel pueden ser probados usando junit por ejemplo sin necesidad de tener las UI.

Por ultimo les dejo estas imágenes:

Aquí pueden ver una vista general de la arquitectura de este patrón:

Y se puede apreciar como el binding crea el mecanismo de comunicación entre las vistas y el viewmodel.

Y en esta otra imagen tienen un ejemplo sobre cómo sería el flujo de eventos en una llamada al sistema.

En la siguiente entrada de la serie veremos la continuación del proyecto creado al inicio y la implementación de este patrón, para mostrar las diferencias respecto al patrón MVC.

{ Leer Más }