Mi cursada - UNQ‎ > ‎Clases‎ > ‎Bitácoras‎ > ‎Bitácoras 2011 S1‎ > ‎

Lunes 4 de abril de 2011 - Application Models

publicado a la‎(s)‎ 4 abr. 2011 16:18 por Nicolas Passerini   [ actualizado el 4 abr. 2011 20:34 por gisela decuzzi ]

Una vista un poco más compleja: pantalla de búsqueda

Arrancamos con una laaaarga disertación que no venía al caso sobre por qué preferimos las metodologías ágiles.

Luego contamos el funcionamiento de la pantalla de búsqueda del ejemplo del Videoclub.
De pasada, vemos que las pantallas de edición y creación de socio ahora incorporan dos selectores. Uno de ellos tiene como conjunto de valores un Enum y el otro una Home.

Pasamos a ver cómo está construida esa pantalla. ¿Qué tenemos como modelo en esta pantalla?
Nos dimos cuenta (o al menos Fede se dio cuenta) de que el objeto detrás de esa pantalla es un "buscador", que tiene:
  • Dos atributos que son los filtros de búsqueda (nombre y dirección).
  • Un atributo de tipo lista que representa el resultado de la búsqueda.
  • Un método que ejecuta la búsqueda, tomando los datos de los filtros y actualizando el resultado de forma adecuada. Esto podría hacerse de muchas maneras, en nuestro caso estamos utilizando una busqueda by example.
En el medio, a Javi se le escapó la palabra DAO y eso motivó ooootra disertación; con un poco de esfuerzo, esta no fue tan larga. :)

Binding de propiedades "anidadas"

Un detalle técnico es que los campos de filtrado no están bindeados contra propiedades del buscador. En cambio el buscador tiene una propiedad "example" que es un Socio; y los campos de filtro se bindean contra propiedades de ese objeto Socio.

Mencionamos que habría tres formas de hacer esto:
  • La que tiene el ejemplo: bindear el Panel contra la propiedad "example" y los campos contenidos en él con propiedades del Socio referenciado por example.
  • Propiedades anidadas, de la forma "example.nombre". Esto es muy común en los frameworks de presentación en tecnología Java.
  • Resolverlo a nivel modelo, agregando una propiedad "nombre" al buscador, que maneje la propiedad internamente.
En este ejemplo preferimos la primera estrategia, pero pueden existir casos en los que sea útil alguna de las otras dos.

Tablas

Las tablas nos permiten mostrar muchos objetos del mismo tipo contenidos en una colección y seleccionar uno de ellos.

Eso nos permite bindear dos propiedades de la tabla:
  • Sus contenidos, contra una colección del modelo.
  • El objeto seleccionado.

También podemos ver que los botones de la tabla se deshabilitan cuando no hay un objeto seleccionado, eso se logra con un binding especial (que se fija que la propiedad sea no nula).

Application Model

¿Qué representa ese objeto "buscador"? Es el modelo de la ventana, sin embargo no puede decirse que sea un objeto de dominio como Socio o Película. Lo diferencian fundamentalmente dos condiciones:
  • Tiene otra naturaleza en cuanto a la forma en que aparece, no está (a priori) entre los conceptos que maneja el usuario.
  • Tiene otro ciclo de vida. Los objetos del dominio se crean, se guardan (utilizando probablemente un repositorio persistente), luego se pueden consultar, modificar, etc. En cambio los objetos de aplicación se usan una sola vez, suelen tener el estado conversacional entre un usuario y la aplicación, representan un caso de uso.

El objetivo es tener un objeto que sea totalmente independiente de la tecnología, pero que tenga todo el comportamiento necesario de la aplicación. Es la representación del comportamiento global de la apliación sin la componente tecnológica.

Consideramos que es más importante la separación entre los componentes de la aplicación que dependen de la tecnología (vista, controller) y los que no (modelos de aplicación o de dominio); en lugar de la separación entre los roles (dominio vs. el resto, vista vs. controlador). Y el application model nos da la herramienta para lograr eso.

Esta estrategia nos permite:
  • Tener un modelo rico, en el cual poder programar y diseñar libremente, sin dependencias tecnológicas.
  • Por ser independientes de la vista pueden ser testeados con herramientas para testeo unitario sencillas (sin la complejidad de las herramientas de testeo automático para interfaces de usuario).
  • Por adaptarse a las necesidades de la vista, simplifican el mapeo que realizan los controllers.

El  application model funcionará como buffer entre la vista y el modelo de dominio y nos va a permitir construir esa parte de la aplicación programando con objetos y en nuestro lenguaje de preferencia, en lugar de tener que adaptarse a un framework, tecnología o lenguaje que no tiene la misma potencia como JSP o XML.

Algunas variantes de ese concepto se pueden ver en el artículo sobr formas de vincular una vista con el modelo de dominio.

Comments