Model View - View Model (MVVM) una explicación sencilla Parte I

Artículo para: Programadores de C# de cualquier nivel

Llevo algún tiempo ya en esto del WPF (unos 4 años) y veo cada vez más malos ejemplos de cómo se programa en esta maravillosa tecnología de Microsoft, que nos lleva a otro nivel en cuanto a interfaces gráficas se refiere.

En lo que a este tema se refiere, Microsoft da unas pautas MUY CLARAS de cómo operar y cómo realizar los desarrollos en esta tecnología, pero parece ser que la gente que viene de Windows Forms no desea adaptarse. Es por ello por lo que escribo este artículo, en pro de ayudar a quien quiera escucharme y siempre buscando un consenso en cuanto a desarrollo de aplicaciones de escritorio y aunque el futuro de Silverlight es muy oscuro, espero que aquellos que programéis aún en esta plataforma os sea también de ayuda.

Este artículo está dividido en 5 partes, porque el modelo MVVM no es trivial y bien requiere de un poco de tiempo para digerirlo correctamente. Si vienes de Windows Forms y estás pensando que puedes hacer lo que siempre has hecho (trabajar por eventos), estás en lo cierto, pero la estás cagando considerablemente. Si haces una aplicación WPF por eventos que tenga más de dos vistas, demuestras que no sabes del tema demasiado; tómate un tiempo para comprender y para ponerte al día, que de verdad, no cuesta nada.

El axioma para todo esto: LOS EVENTOS SON MALOS, no los uses como siempre lo has hecho. Esta tecnología no está pensada para el click de un botón o para el text_changed de un cuadro de texto, cambia tu mentalidad y empieza a pensar un poco más allá.

Y ahora el "quid" de la cuestión: ¿Cómo funciona ésto? La tecnología Windows Presentation Foundation de Microsoft tiene un "modus operandi" muy curioso, que nos permitirá explotar al máximo la capacidad de nuestras tarjetas gráficas modernas. No siendo aplicaciones de tipo videojuegos, las aplicaciones WPF pueden ser tan preciosas y tan bien diseñadas que nos sintamos como jugando con ellas; como programadores este tiene que ser nuestro objetivo final: el usuario se ha de sentir MUY cómodo usando nuestras herramientas de software.

El patrón MVVM consiste en unas buenas prácticas que yo, como experimentado programador de esta tecnología definiría de la siguiente manera (aunque como todo, es discutible):

• Separar la vista de la funcionalidad que da soporte a la misma (a esto lo llamamos View)
• Crear una capa que sea la interlocutora entre el negocio y la vista (que se llama View Model)
• Por último, hacer una capa de negocio que NO TENGA NADA QUE VER con la vista (lo has adivinado, el Model).

MVVM conceptualmente

Enlaces prohibidos: desde el Model está TERMINANTEMENTE PROHIBIDO conectar con la View.

Entonces, ¿Cómo se comunican las distintas entidades en este modelo? Es muy sencillo:

• El usuario comunica directamente SOLO con la View.
• La View comunica directamente SOLO con el View Model.
• El View Model hace de interlocutor entre la View y el Model.

Para ello, desde Visual Studio crearemos una solución en blanco y haremos lo siguiente:

• Crearemos una nueva solución en blanco en Visual Studio:

• Crearemos un nuevo proyecto de WPF, el cual será la View.

• Crearemos un nuevo proyecto de Librería de Clases, el cual será el View Model.

• Crearemos uno o más proyectos (normalmente son varios), de tipo Librería de Clases, los cuales en su conjunto crearán el Model.

Después de toda la operativa, nos debería quedar de la siguiente manera el árbol de proyectos:

¿Cómo relacionarlos?

• El proyecto View referenciará al View Model. Nunca tendrá referencias al Model.
• El proyecto View Model referenciará a uno o varios proyectos del Model. Nunca tendrá referencias al View (o tendríamos el problema de la referencia circular).
• Los proyectos del Model NUNCA referenciarán ni a la View, ni al View Model.

Con las relaciones definidas, la comunicación solo se produce en un solo sentido:

Sentido de la comunicación por referencias a proyectos

Si bien esta comunicación es muy buena, no es suficiente porque necesitamos mecanismos para poder informar al resto de componentes en el otro sentido. En un próximo artículo os explicaré los eventos personalizados y un sencillo sistema gestor de Weak Events.

Pero antes de abordar temas más complejos, en el siguiente artículo os explicaré los XAML's y los bindings, que es algo vital en todo este asunto.

Espero que os haya gustado esta pequeña introducción y también espero sinceramente vuestros comentarios, que serán bienvenidos y de los cuales se aplicarán las correcciones que considere oportunas.

Unknown

Author y editor