Iniciemos este post, con la definición inicial de lo que vamos hablar.
¿Qué es MVVM?
Es el patrón de diseño natural para plataformas XAML, este
patrón aprovecha al máximo el enlace a
datos {Binding}, diseñar nuestras aplicaciones bajo este nos brinda una gran
cantidad de ventajas, mencionaremos algunas:
·
Separación de preocupaciones, es decir, tienes
en diferentes componentes bien definidos una sola funcionalidad, tienes la
ventaja de que un componente ejecute una solo funcionalidad.
·
Pruebas unitarias están podrán evaluar que los
métodos y objetos funcionen de una manera correcta y consistente, esta pruebas
se pueden hacer de una forma más eficiente. Al no tener una separación de las
funcionalidades no es más complicado escribir estas pruebas en código.
·
El mantenimiento de código es más rápido, al
estar separado en capas el código nos facilita esta tarea.
·
La consistencia del código y nuestra aplicación
será más acoplable, nos permite reutilizar código de una forma más sencilla.
·
El flujo de trabajo entre diseñadores y
desarrolladores es más ágil, así cada uno se focaliza a su trabajo, el diseño y
navegación por una parte y en el desarrollo te enfocas a la funcionalidad y
como codificar esto.
Al utilizar este tipo de patrones se beneficia la aplicación
sin importar el tamaño o funcionalidad.
Focalicemos esto en que los patrones de diseño no son un
Dogma u obligación implementarlos, son sugerencias para aprovechar al máximo
las características de la plataforma de desarrollo (XAML y .Net). Si bien es
recomendable la utilización de esto patrones, cada quien al momento de
desarrollar decide utilizarlos o no.
Esquematicemos esto para comprender un poco más la forma
como deberíamos implementar este patrón, este debería de contar con tres piezas
(Model,View,View-Model)
View:
1.
Contendrá todo nuestro código xaml (páginas,
user control, estilos, diccionarios de recursos, data template, etc)
2.
Define la interfaz de usuario.
3.
Define la estructura y apariencia de lo que el
usuario ve en pantalla.
4.
Se sugiera poco o nada de Code-Behind.
5.
La vista se actualiza a través de las
expresiones Bindings
View-Model:
1.
Es una abstracción de la Vista (View)
2.
Se implementa la lógica de la presentación
3.
Adapta el modelo a la vista.
4.
Expone propiedades a las que se enlaza la vista
(datos y comandos)
5.
Expone métodos que los comportamientos de una
vista pueden invocar.
6.
Desacoplamiento y Testeability es el objetivo
principal
Model:
1.
Es nuestro dominio, lo que manejaremos como
datos
2.
Objetos de datos
a. DTO (Data Transfer Object), clases
POCO (Plain Old CLR Objects)
b.
Modelo de datos generado
3.
Capa de servicios
a.
Repositorios
b.
Objetos de Negocio
4.
Clases que representan todos los datos de la
aplicación
Relación entre las tres piezas:
a.
Generalmente una vista tiene un View-Model.
b.
Un View-Model puede ser usado en una o más vistas
c.
Un Model puede ser utilizado en uno o más
View-Models
Un View-Model bien construido se puede utilizar no solo en
una aplicación sino utilizarlo en más de una aplicación (reutilizando código).
Existen 2 estrategias para relacionar el View con el
View-Model, como sabe una vista que View-Model va utilizar:
1.
Primero la vista (View First)
a.
La Vista crea el View-Model (en XAML o
Code-Behind).
b.
La vista tiene inyectado el View-Model
(propiedad o constructor).
2.
Primero el View-Model (View-Model First)
a.
El View-Model crea la vista, se enlaza así mismo
a la vista.
Pensando en MVVM
Para realizar algún cambio dentro de nuestra vista, es
importante tener enlazados todos los controles y sus propiedades, es decir,
para cambiar un color, posición, animar, etc.
Para que la vista ejecute código los controles de la vista
se enlazan a propiedades ICommand, los comportamientos de la vista pueden
invocar métodos o enlazar un evento a un comando.
En el siguiente Post, vamos a realizar el ejemplo práctico de este tema.
