Hace ya unos años que vengo haciendo aplicaciones, tanto móviles como de escritorio, utilizando el patrón de diseño MVVM, lo que básicamente desacopla la vista del modelo y nos deja un actor en medio para hacer todo ese proceso, pero ¿Qué significan exactamente las siglas? ¿Qué hay que poner en cada una? ¿una llamada a una base de datos local se hace desde el ViewModel, la View o el Model?
Evidentemente no voy a sentar las bases de nada. En lugar de eso te voy a contar la estrategia que sigo desde hace mucho tiempo.
En las aplicaciones en las que he sido el responsable del diseño he utilizado una estructura defensiva cuando los componentes del equipo tenían menos experiencia y que así poco a poco interiorizasen los conceptos que hay detrás de ese desacople de cada capa de la aplicación.
Sobre la View de este patrón hay poco que contar ya que se encarga justo de eso, de hacer una representación gráfica del Model. Sin embargo esto no lo hace directamente, utiliza a su amigo el ViewModel para saber qué y cómo hacerlo. Para ello, por una cuestión lógica, nuestra View debe saber de la existencia del ViewModel del cual recibirá toda la información necesaria para adaptar la visualización y permitir las interacciones del usuario final.
Y aquí es donde viene lo bueno, nuestro ViewModel no tiene ni idea de quién está conectado a él y funciona como si fuese un puente entre el Model y quien esté conectado a él, pero eso no significa que no tenga responsabilidades ya que con cada actualización que reciba de View, necesitará actualizarse y para eso preguntará a Model qué debe hacer para informar a View.
Supongo que ahora te surge una duda, ¿Qué representa Model entonces? ¿No debería ser sólo el modelo de datos de la aplicación?
(Evidentemente esta es mi visión sobre MVVM y si tienes una diferente, me encantaría verla.)
Para mi, el Model representa todo aquello que no signifique la representación gráfica de la aplicación, de manera que será responsable de interactuar con elementos como base de datos local, llamar al exterior para recibir datos que necesite, manipularlos y prepararlos para que la parte visual sólo tenga que representarlos gráficamente.
Por cada tipo de interacción que necesito monto un Service acompañado por su correspondiente Interface con el contrato a implementar, por lo que me quedaría algo más o menos así:
- View (Ensamblado propio)
- ViewModel (Ensamblado propio)
- Model (Conjunto de ensamblados)
- Interface (Ensamblado propio)
- Service (Ensamblado propio)
- Models (Ensamblado propio)
Bien, pues ahora que ya sabes cómo he estado trabajando la estrategia MVVM, te quiero contar porqué estoy haciendo una prueba de concepto para cambiarlo.
Desde hace algún tiempo utilizo ReactiveUi, lo que hace que todo se convierta en programación funcional reactiva, pero claro, siempre tenemos que lidiar con los errores por los cambios de estado del modelo y eso me llevó a preguntarme, ¿hay algún modo de reducirlo?
Pues bien, en esas estoy, si cada vez es más habitual, al menos para mí, utilizar las capacidades funcionales de C#, ¿y si utilizo un lenguaje funcional para hacerlo? ¿tendré alguna ventaja?
Y aquí es donde entra F#, puedo seguir en la plataforma que me gusta .NET y utilizar lo mejor de los dos mundos, orientación a objetos con C# y funcional con F#.
Todavía no tengo claro que la implementación y la interoperabilidad vaya a ser la adecuada, aunque estoy bastante convencido de que va a ser un cambio interesante de explorar.
Más adelante, cuando tenga una aplicación más seria que un Hola mundo! volveré a escribir con los detalles, los retos que me he encontrado y cómo los he ido solucionando.
Hasta entonces, espero que disfrutes de tu día a día. Pásalo bien!
darioDotNet 