MVVM Light: ¿Qué es?

Empezamos con la primera parte de la serie de artículos de MVVM Light, en concreto con la gran pregunta:

¿Qué es exactamente MVVM o MVVM Light?

Vamos a empezar explicando qué es MVVM:

MVVM es un patrón de diseño que entra dentro de los llamados patrones mv* como podrían ser:

Ambos son patrones muy usados a la hora de crear la arquitectura de la aplicación. De MVP ya hemos hablado en otro artículo y bueno, MVVM es una alternativa mejor a la hora de desarrollar aplicaciones tanto WPF, Silverlight y Windows Phone 7.

Antes de entrar en explicaciones concretas, os dejo un diagrama que os ayudará a entender las cosas:

Como podéis ver aquí, existen tres componentes en este patrón: Model-View-ViewModel, osea, MVVM.

En el Modelo irá toda la lógica de negocio de nuestra aplicación, como podría ser la clase Libro, Persona, Factura… Este tipo de clases tambien son llamadas POCO’s (Plain Old C# Objects), o sea, clases básicas sin ninguna funcionalidad de WPF ni Silverlight.

El ViewModel como su nombre indica, es el modelo de la vista, o dicho de otra forma, es donde irá todo el trabajo que la vista necesita hacer. Si tomamos como ejemplo mi ApuntaNotas, el ViewModel se encargaría de añadir nuevas notas cuando el usuario hace click en el botón, borrar notas, renombrarlas, cambiarles la categoría… En resumen, el ViewModel hace todo el trabajo de la vista que tiene que ver con datos.

La Vista como cabe de esperar será la que contendrá el XAML de nuestra aplicación WPF, Silverlight o Windows Phone 7. Nada raro aquí.

Eso si, todo el mundo se pregunta… ¿Y el Code-Behind de la vista? ¿Vale para algo?

Por supuesto que sí, es un tema controvertido quizá, el code-behind en aplicaciones WinForms por ejemplo ha sido siempre usado para hacer todo el trabajo de la vista. Luego dijeron que eso estaba mal y decidieron delegar todo ese trabajo a un controlador y dejaron el code-behind inutil sin ningún uso.

En MVVM el code-behind es bastante usado, ¿Para qué exactamente? El code-behind lo usaremos para hacer todo el trabajo que tiene que ver con la vista en sí. ¿Recuerdas que dije que el ViewModel haría todo el trabajo de la vista relacionado con datos? Pues ahora el code-behind hace el trabajo restante, o sea, lo que tiene que ver exclusivamente con la vista.

Por ejemplo… Imaginad que si seleccionamos un elemento de un ListBox queremos que cierto TextBox coja el foco; esto es cosa de la vista en sí, no tiene que ver con datos ni nada así que el mejor lugar para hacerlo es el code-behind.

Explicandolo de otra forma que quizá os quede más clara:

Tenemos una aplicación para mostrar una serie de resultados que extraemos de una base de datos.

Para ello tenemos un ViewModel que extrae esos datos del modelo, y prepara esos datos para que una vista pueda usarlos. El ViewModel en sí no sabe nada acerca de las vistas, éste simplemente tiene un conjunto de propiedades para que una vista pueda hacer DataBinding a ellas (como podeis ver en el diagrama de antes). A este ViewModel podemos asignarle cualquier numero de vistas que queramos y dichas vistas representará esos datos como quiera.

Entonces imaginemos que una de esas vistas representará esos datos usando graficas y esas graficas contendrán cosas como animaciones, por ejemplo dandole a un botón la grafica hace una animación chula para mostrar los datos. ¿Quien ha de hacer ese trabajo? Está claro que el ViewModel no, puesto que el ViewModel no sabe nada acerca de las Vistas que lo están usando y si tuviera que implementar cosas por cada vista que lo use, perdería ya el desacople, ¿no? Así que es el code-behind el que hace estas cosas puesto que son cosas que solo atañen a la vista y nadie más.

Hasta aquí es básicamente MVVM, queda algo importante que contar, los comandos, pero eso lo dejaré para la próxima parte donde ya pondré un ejemplillo para que todo esto quede bien claro :)

Tags: , , ,

8 comentarios

  1. Hasta ahora es lo mas claro que he encontrado sobre este patron en wpf

  2. Gracias.

    La verdad es que es un patrón bastante joven, por eso es tal la falta de información. Tengo en mente meter más contenido sobre MVVM en un futuro (A ver si acabo el tema de LINQ que me tiene absorbido :P )

  3. Miguel Angel Reyes Xinaxtle

    cual es la mejor manera de representar datos en graficas, sabes de algunas herramientas?

    En mi trabajo van a implementar este modelo y lo que he escuchado es que el code-behind no se utilizara mas entonces eso me tiene confundido

  4. Hola Miguel Angel,

    Como herramientas para representar gráficas (charts) son muy útiles las del WPF Toolkit (son un conjunto de herramientas que complementan y amplian lo que WPF ofrece de por si)

    Puedes bajarlo desde aquí:

    http://wpf.codeplex.com/

    Sobre no usar más el code-behind. Como ya expliqué, el code-behind solo se usa en casos puntuales y solo para uso exclusivo de la vista.

    O sea, si una gráfica necesita X datos, esos se proveen desde el ViewModel, pero por ejemplo si al hacer click en un botón necesitas que un control coja el foco, al ser eso una operación de la vista y que solo le concierne a ella, eso se hará en el code-behind.

    Un saludo.

  5. Compact y claro muy buen trabajo.

  6. WPF Toolkit es compatible con el visual studio 2010?

Dejar un comentario