Application model. Extendiendo el MVC.

Introducción

En Arena cada vista requiere un modelo. Esto implica encontrar una abstracción que pueda cumplir esa responsabilidad. Algunas pantallas como el conversor de millas a kilómetros utilizan un objeto de dominio como modelo; pero cuando la complejidad de la interacción con el usuario crece, no nos alcanza con tratar de resolverlo con un objeto de dominio como Celular, Socio o Película.

Entonces nuestro 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 aplicación sin la componente tecnológica.

Algunos ejemplos

Una pantalla de búsqueda de clientes de una compañía que vende celulares:

image

Una ventana para crear un pedido, que selecciona cliente y producto (y también permite darlos de alta):

image

E incluso podemos pensar que una pantalla de alta o edición puede manejarse con un application model, esto permite no tener una referencia extra para conocer al home o repositorio:

Objetivo

Consideramos 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). Y el application model nos da la herramienta para lograr eso.

Esta estrategia nos permite:

El application model funciona 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. Algunas variantes de ese concepto se pueden ver en el artículo formas de vincular una vista con el modelo de dominio.

Objeto de dominio vs. application model

Podemos encontrar dos diferencias importantes:

Esquema MMVC

El objeto Application Model da origen al esquema MMVC [1]:

image