MVVM y evitando el objeto Monolithic God

Question

Estoy en la etapa de finalización de un gran proyecto que tiene varios componentes grandes: adquisición de imágenes, procesamiento de imágenes, almacenamiento de datos, E/S de fábrica (proyecto de automatización) y muchos otros.

Cada uno de estos componentes es razonablemente independiente, pero para que el proyecto se ejecute como un todo necesito al menos una instancia de cada componente. Cada componente también tiene un ViewModel and View (WPF) para supervisar el estado y cambiar cosas.

Mi pregunta es el método más seguro, más eficiente y más sostenible de instanciar todos estos objetos, suscribir una clase a un evento en otro y tener un ViewModel y una vista comunes para todo esto.

¿Será mejor si tengo una clase llamada Dios que tiene una instancia privada de todos estos objetos? He hecho esto en el pasado y lo lamenté.

¿O sería mejor si Dios dependiera de las instancias de Singleton de estos objetos para hacer rodar la pelota?

Alternativamente, debería Program.cs (o donde Main (...)) instanciar todos estos componentes, y pasarlos a Dios como parámetros y luego dejar que Él (snicker) y Su ViewModel se ocupen de los detalles de ejecución este proyectos.

Cualquier otra sugerencia que me gustaría escuchar.

¡Gracias!

Answer 1

Mi forma preferida de obtener ViewModels es usar un ViewModelLocater. Básicamente es el objeto de Dios como usted implica, pero su única responsabilidad es crear cada ViewModel y mantener una referencia al mismo. Normalmente agrego el VML a los recursos de la aplicación y cada vista es responsable de configurar su DataContext correcto en ViewModel. Si está suscribiendo varios eventos, puede hacer que su VML los conecte manualmente, o puede crear la VM que arroja los eventos primero y pasarlos a la máquina virtual dependiente en su constructor.

Answer 2

Espero haber entendido bien su pregunta. Creo que usar God ViewModel no es una buena idea. es mejor tener un único modelo de vista para cada una de sus vistas e instanciar todos los modelos de vista relacionados en ese modelo de vista. luego puede usar un mediador para enviar mensajes entre los modelos de vista de esa vista y otras vistas, de forma segura. También sugiero usar comandos wpf en lugar de eventos. Puede encontrar un artículo más grande sobre mediador en here.

Answer 3

Estas preocupaciones son atendidas utilizando bastante bien de Microsoft "biblioteca de aplicaciones compuestas" (también conocido como Prisma) un marco para el desarrollo de compuestos aplicaciones WPF:

http://msdn.microsoft.com/en-us/library/ff647752.aspx

http://msdn.microsoft.com/en-us/library/ff648611.aspx

• Componer sus puntos de vista: Prism tiene un concepto de una ventana de shell de aplicación y un administrador de región. El shell actúa como una página de diseño básica en la que se definen las regiones nombradas de marcador de posición, p. "MainMenu" y "TabInterface". Envuelve las referencias a sus vistas y modelos de vista en clases de módulo, p. "MainMenuModule" y "TabInterfaceModule", y definir a qué región debe asociarse el módulo. Prism creará sus vistas e inyectarlas en las regiones del caparazón cuando se inicie la aplicación. Esto le permite componer sus puntos de vista independientemente el uno del otro.

• Comunicación entre viewmodels: Prism admite un patrón de mediador denominado "Event Aggregator". Básicamente puedes publicar y suscribirte a mensajes a través del agregador de eventos desde tus viewmodels. Esto permite que los modelos de vista se comuniquen libremente a través de mensajes, en lugar de tener que conocerse unos a otros y enganchar eventos.

defensores prisma y apoya las pautas de desarrollo de componentes independientemente uno del otro de una manera imprecisa, sin introducir objetos Dios, y de acoplamiento. Una gran parte de Prism es también su uso de IOC e inyección de dependencia, por lo que las pruebas unitarias se vuelven mucho más fáciles también.

me encontré con el siguiente artículo de una buena introducción práctica al uso de Prism y MVVM:

http://www.developmentalmadness.com/archive/2009/10/03/mvvm-with-prism-101-ndash-part-1-the-bootstrapper.aspx

Answer 4

Tome un vistazo a algunos marcos de inyección de dependencias tales como la Unidad (que utiliza CAL), el castillo de Windsor o primavera. RED.

Answer 5

Puede usar Controladores (ApplicationController, Use-Case Controllers) en lugar de una clase 'God'. Los controladores son responsables de crear los objetos de ViewModel y median entre ellos.

Cómo funciona esto se muestra en el proyecto WPF Application Framework (WAF).