Aclaración de MVVM

12

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

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

Parte de la transición a MVVM es bastante sencilla. Nuestra Gui seguirá conteniendo las vistas, nuestro BusinessOjbects seguirá conteniendo el modelo y nuestro DAL seguirá interactuando con el DB (aunque la tecnología para implementarlas 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 rellene los controles en las vistas (es decir, GetCustomerList que devolvería una lista de objetos del Cliente o las funciones típicas de CRUD).

El problema principal que tenemos es si el patrón MVVM requeriría un componente adicional para alojar 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 modelos de visualización?

    
pregunta user7676 31.01.2013 - 18:00

3 respuestas

18

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

Eric Evans utiliza 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 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 está siguiendo el patrón MVVM, entonces las reglas del dominio van, sin duda, en 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 que necesita la vista en el modelo correspondiente, actualizar el modelo cuando cambia la vista, escuchar los eventos en el modelo y propagar esos eventos a la vista, permitiendo que la vista se actualice cuando el modelo se actualice entre bambalinas (si corresponde).

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

    
respondido por el Pete 31.01.2013 - 20:31
4

Sí.

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 de VM. Esa unión se traduce en | implica que la vista ya no es la capa que "hace la llamada" para recuperar algo más. La llamada para la recuperación de datos provendrá de la VM en su lugar.

Para explicar mejor: Sí, un objeto dentro de la Vista deberá cambiarse para desencadenar la secuencia de cosas que realizará la llamada. Pero la vista no hace la llamada en sí misma. Y en este caso, considero que un clic de botón es equivalente a que algo dentro de la Vista cambia, pero aún no hace la llamada.

En el primer caso, ese objeto de Vista estará vinculado a un objeto de máquina virtual. La máquina virtual debe estar escuchando un evento de propiedad modificada en el objeto enlazado. El evento de cambio de objeto se puede conectar a una función de VM para realizar la llamada del 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 algún código de WinForm se usa para hacer una llamada a la capa de DB directamente desde el código subyacente de la GUI de WinForm. Ese enfoque rompe la separación que proporciona MVVM.

    
respondido por el GlenH7 31.01.2013 - 18:04
3

Tienes razón en que básicamente estarías reemplazando tu dll BusinessLogic con tu capa ViewModel, sin embargo, creo que la mayor diferencia que enfrentarás es la forma en que la capa View / UI interactúa con tu capa ViewModel / BusinessLogic.

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

Por ejemplo, con WinForms, es posible que tenga un DataGrid y un Button, y cuando hace clic en ese botón, llama a BusinessLogicLayer.GetProducts() y carga los objetos del producto resultante en el DataGrid.

Con WPF, tendría un ViewModel que contiene un ObservableCollection<Products> y un ICommand GetProducts , y la ejecución del 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 represente su ViewModel usando un DataGrid para la colección de Productos, y un Botón para el comando GetProducts.

En realidad escribí una publicación bastante reciente para mi blog sobre el cambio en La mentalidad al pasar de Winforms a WPF en mi blog , y creo que la mejor manera de resumir la diferencia es con estas fotos:

    
respondido por el Rachel 31.01.2013 - 20:16

Lea otras preguntas en las etiquetas