Clarificación MVVM

15

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.

AsIs Architecture

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?

usuario7676
fuente
Esto suena un poco como una solución en busca de un problema. ¿Hay alguna razón convincente por la que te estás mudando a MVVM? Soy fanático del patrón, pero ¿su solución anterior no funcionaba? El modelo de vista es como un presentador supervisor. Contiene lógica de presentación y datos de superficie a través del enlace de datos. Debe conocer su lógica de negocios y poder llegar a ese nivel, pero no colapsaría la lógica de negocios en el modelo de vista en sí.
Jeremy Likness 01 de

Respuestas:

19

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.

Pete
fuente
1
Excelente respuesta Me gusta el punto de asegurarme de que ViewModel solo contenga lógica de presentación. ¿Puedes agregar algún enlace relacionado con tu punto Eric Evans?
user7676
Dudo que pueda encontrar un enlace, porque creo que lo obtuve de su libro, Diseño impulsado por dominio. De todos modos, creo que es un excelente ejemplo de la diferencia entre el dominio y la lógica de la aplicación. Más información sobre el libro aquí books.google.dk/books/about/…
Pete
5

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.


fuente
Gracias por la confirmación. Entendemos el matiz de cómo la Vista interactúa con ViewModel y mantendremos el modelo de enlace y soltaremos la "llamada".
user7676
Noté que esta respuesta perdió un voto positivo. Me gustaría saber si el votante comentaría por qué. O quizás agregue su propia respuesta si no comparten este punto de vista.
user7676
1
Estoy de acuerdo en que la capa de lógica de negocios está representada por la capa de VM, sin embargo, creo que partes de su respuesta pueden ser confusas. La Viewcapa está destinada a ser una representación visual del modelo o modelo de vista, por lo que en lugar de decir que el evento click está conectado a una llamada de función en la máquina virtual, una mejor definición sería decir que el comando en la máquina virtual se representa como un botón en la capa de vista. Además, yo normalmente no me gusta mi capa del Modelo de poder acceder a la DAL directamente, por lo que mi flujo de aplicación típicamente ir VM -> DAL -> DB, donde las VMy DALambos utilizan el llano Modelobjetos de datos.
Rachel
44
No estoy de acuerdo con esta respuesta. ViewModel es el modelo de la vista, contiene lógica de vista, no lógica de negocios. ViewModels son parte de la capa de presentación
simoraman
1
@simoraman: el patrón MVPVM está alineado con lo que estás sugiriendo. Creo que MVPVM es un buen patrón, pero un poco pesado para aplicaciones más pequeñas. Realmente te animo a que pongas tus pensamientos en una respuesta y contribuyas a esta pregunta.
5

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:

Rachel
fuente
1
Estoy de acuerdo con GlenH7, esta es una buena respuesta para alguien que comienza con WPF. Obtenemos el cambio de paradigma de la interacción entre la Vista y el Modelo de vista, por lo que esto no fue realmente el tema de la pregunta que hice.
user7676