Clarificación MVVM

Estamos a punto de escribir nuestra primera aplicación WPF y nos estamos familiarizando con el patrón MVVM. Hemos creado muchas aplicaciones Winform y tenemos una arquitectura que ha sido muy exitosa para nosotros. Tenemos algunos problemas para traducir esa arquitectura o determinar dónde encajan ciertas piezas de nuestra arquitectura en el modelo MVVM.

Históricamente tenemos una Gui (el exe principal) que luego se comunica con un dll BusinessLogic. BusinessLogic se comunica con un dll DAL a través de un servicio web y el DAL interactúa con el DB. El DAL, BusinessLogic y la GUI hacen referencia al mismo dll de BusinessObjects.

Parte de la transición a MVVM es bastante sencilla. Nuestra interfaz gráfica de usuario seguirá conteniendo las vistas, nuestros BusinessOjbects seguirán conteniendo el modelo y nuestro DAL seguirá interactuando con el DB (aunque la tecnología para implementarlos puede cambiar).

De lo que no estamos seguros es de nuestro componente BusinessLogic. Históricamente, esto proporcionaría funciones para que la GUI llame y luego complete los controles en las vistas (es decir, GetCustomerList que devolvería una lista de objetos del Cliente o las funciones CRUD típicas).

El problema principal que tenemos es si el patrón MVVM requeriría un componente adicional para albergar los ViewModels o si simplemente cambiamos nuestra forma de pensar y migramos lo que hemos usado como nuestro componente BusinessLogic a los ViewModels.

¿Nuestro componente BusinessLogic representa los ViewModels?

En general, no colocaría la lógica empresarial en la capa del modelo de vista. Pero el término "lógica de negocios" es engañoso.

Eric Evans usa un modelo donde la lógica de negocios se divide en dos categorías

• Lógica de dominio: lógica relacionada con el dominio del problema real que está resolviendo
• Lógica de la aplicación: lógica relacionada con el hecho de que está creando una aplicación

Menciona el ejemplo de una aplicación contable. Las reglas sobre cuentas, publicaciones, cuentas de impuestos, etc. son reglas de dominio, reglas relacionadas con el dominio de la contabilidad. La lógica sobre la importación / exportación de CSV no tiene nada que ver con el dominio de la contabilidad. Estas reglas existen simplemente porque estamos creando una aplicación de software. Estos son ejemplos de lógica de aplicación.

Las reglas de dominio NUNCA deben entrar en la capa del modelo de vista. Si sigue el patrón MVVM, las reglas del dominio van, sin lugar a dudas, a la capa del modelo.

Las reglas de aplicación, como la importación / exportación CSV, podrían ir en la capa del modelo de vista. Pero personalmente, preferiría separar eso en una capa lógica de aplicación separada.

El modelo de vista debería ser muy simple. Buscar los datos necesarios para la vista en el modelo correspondiente, actualizar el modelo cuando la vista cambia, escuchar eventos en el modelo y propagar esos eventos a la vista, permitiendo que la vista se actualice cuando el modelo se actualiza detrás de escena (si es aplicable).

Personalmente, me aseguraría de que la capa del modelo de vista contenga solo un tipo de lógica, la lógica de presentación.

Si.

La capa de lógica de negocios está representada por la capa de VM. Así que solo migra tu modelo mental.

Para ayudar con la migración de su modelo mental, un ligero matiz es que los objetos GUI (Ver) deben estar vinculados a objetos dentro de la capa VM. Esa unión se traduce en | implica que la Vista ya no es la capa que "realiza la llamada" para recuperar otra cosa. La llamada para la recuperación de datos vendrá de la VM en su lugar.

Para explicar mejor: Sí, un objeto dentro de la Vista tendrá que cambiar para activar la secuencia de cosas que harán la llamada. Pero la Vista no hace la llamada en sí. Y en este caso, considero que hacer clic en un botón es equivalente a que algo dentro de la Vista cambie, pero aún no realice la llamada.

En el primer caso, ese objeto Ver estará vinculado a un objeto VM. La VM debería estar escuchando un evento de cambio de propiedad en el objeto vinculado. El evento de cambio de objeto se puede conectar a una función de VM para realizar la llamada Modelo.

En el segundo caso (evento de clic de botón), el evento de cambio (clic) se puede conectar a una llamada de función expuesta por la VM.

De cualquier manera, siempre es un evento que se secuencia en la VM que luego llama al Modelo que a su vez llama al DAL / DB.

Lo menciono porque parte del código de WinForm se usa para hacer una llamada a la capa de base de datos directamente desde el código subyacente de la GUI de WinForm. Ese enfoque rompe la separación que MVVM está proporcionando.

Tiene razón en que esencialmente estaría reemplazando su dll BusinessLogic con su capa ViewModel, sin embargo, creo que la mayor diferencia que enfrentará es cómo interactúa la capa View / UI con su capa ViewModel / BusinessLogic.

En WinForms, la GUI es su aplicación y es responsable del flujo de la aplicación. En WPF / MVVM, sus ViewModels son su aplicación, y la GUI se convierte en una interfaz fácil de usar para interactuar con los ViewModels.

Por ejemplo, con WinForms, puede tener un DataGrid y un Botón, y cuando hace clic en ese Botón, llama BusinessLogicLayer.GetProducts()y carga los objetos del Producto resultante en el DataGrid.

Con WPF, tendrías un ViewModel que contiene an ObservableCollection<Products>y an ICommand GetProducts, y ejecutar el comando llama al DAL y carga la colección de productos. Pero para proporcionar una interfaz fácil de usar para esto, crearía una Vista que representara su ViewModel usando un DataGrid para la colección de Productos y un Botón para el comando GetProducts.

De hecho, escribí una publicación bastante reciente para mi blog sobre el cambio de mentalidad al pasar de Winforms a WPF en mi blog , y creo que la mejor manera de resumir la diferencia es con estas imágenes: