El modelo MVC tiene unos componentes básicos, datos, interfaz de usuario y controlador, están separados en tres componentes independientes, pero si ocurre un cambio en la lógica de negocio, esta debe ser la encargada de realizar cualquier cambio que se produjera en la interfaz gráfica o capa de cliente. Por otra parte MVVM, tiene de igual modo el modelo y la vista, pero si se produjera un cambio en la interfaz gráfica atendiendo a una acción externa, el resultado se actualizará en el modelo o si se produce un cambio en el modelo, se actualiza automáticamente en la vista y el encargado de esta característica, es el viewmodel.

Como se puede apreciar en las imágenes, en MVC el controlador es el encargado de sincronizar los datos en la vista a través del modelo y en el MVVM, el viewmodel recibe notificaciones desde el modelo y envía notificaciones a la vista y esta mediante data binding y commands, actualiza datos y ejecuta acciones respectivamente en el viewmodel actualizando este el modelo. En definitiva, la vista debe estar desacoplada completamente de la lógica de la aplicación.

Si queremos usar MVVM, aconsejo que la aplicación desarrollada haga lo que queramos sin interfaz gráfica, es decir que nos olvidemos de la vista (de momento), pero sin dejar de pensar en ella, es decir, si creamos una aplicación que gestione una cafetería, las entidades o modelos, artículos, familias, ticket, líneas de ticket, etc. serían simples clases, tendríamos una clase encargada de acceder a la base de datos y cargar esos modelos y viewmodel, se encargaría de gobernar todas ellas, pero como he dicho, sin crear la vista, debemos poder generar un ticket con sus líneas y artículos o realizar búsquedas de artículos en base a su familia, etc, pero sin mostrarlos, simplemente acceder a la colección de entidades con datos asignados con la capacidad de poder guardarlos u obtenerlos del centro de datos, sea el que sea base de datos, xml, texto o servicio.

Ya que conocemos grosso modo las características de ambas arquitecturas, nos centraremos en el segundo modelo y en el que Microsoft con WPF y Android han llevado a cabo, por una parte aunque Binding ya se usaba con Windows Forms, WPF lo ha integrado en la misma API, de modo que a mi personalmente, Windows Form, ha quedado relegado prácticamente en todos mis proyectos de escritorio y uso WPF que está rodado y es consistente. Databinding en Android, es una tecnología relativamente reciente para esta plataforma y con la nueva arquitectura de componentes ha sido llevada al terreno de la solidez a mi parecer.

Como elementos comunes en sendos ejemplos, incluiremos una clase de familia de artículos, otra clase de artículo y una clase de acceso a datos, la cual no indicaremos la tecnología de acceso a datos, sino solo sus métodos y por último la clase viewmodel. Otro de los aspectos que no voy a tener en cuenta, es la nomenclatura en el diagrama de clases, usaré por defecto la usada por Microsoft aunque en el proyecto si usaremos la nomenclatura usada en ambas plataformas. En cuanto al tipo de aplicación, una será de escritorio para WPF y C# y otra para dispositivo móvil en Android y Java, pero el fin de la tetralogía es conocer la implementación de la arquitectura, no profundizar en el tipo de aplicación.

La aplicación mostrará una lista de familias incluido una familia que indique «todas los artículos», al seleccionar una familia, se filtran todos los artículos de una familia y al seleccionar un artículo, se muestra el artículo en detalle.

En el siguiente post comenzaremos con la plataforma Windows y binding con WPF, pasando a la plataforma Android y por último analizaremos los pros y contras de ambas.