mvvmlight galasoft c# wpf mvvm mvvm-light

c# - galasoft - nuget mvvmlight



Crear una estrategia de diálogo amigable MVVM (3)

Al diseñar una interfaz de usuario con MVVM, el objetivo es separar las preocupaciones de la Vista de las preocupaciones de ViewModel. Lo ideal es que ViewModel no dependa de ningún componente de vista. Sin embargo, esta es la norma idal y otra regla de MVVM es que debe diseñar su aplicación como lo desee.

En el área que proporciona un servicio que muestra diálogos, hay dos enfoques diferentes que flotan alrededor:

  1. Implementar DialogService en la Vista (por ejemplo, ver http://geekswithblogs.net/lbugnion/archive/2011/04/13/deep-dive-mvvm-samples-mix11-deepdivemvvm.aspx Sample 03).
  2. La implementación de un componente de servicio que no está conectado a la vista (por ejemplo, consulte http://blog.roboblob.com/2010/01/19/modal-dialogs-with-mvvm-and-silverlight-4/ )

Ambos enfoques se basan en una interfaz que define la funcionalidad que proporciona el servicio. La implementación de este Servicio se inyecta en ViewModel.

Además, ambos enfoques tienen sus ventajas y desventajas específicas.

  • El primer enfoque también funciona bien para WP7, sin embargo, requiere una clase base de vista común, ya que contiene la implementación del servicio de visualización.
  • El segundo enfoque funciona bien para SilverLight y WPF y Appleals, ya que mantiene el servicio separado de la vista y no impone ninguna restricción en la vista.

Otra posible solución es usar mensajes para mostrar los diálogos.

Independientemente del enfoque que esté utilizando, trate de mantener la Vista y el Modelo de Vista desacoplados mediante el uso de un patrón IoC (inversión de control), es decir, defina una interfaz para que pueda usar diferentes implementaciones. Para enlazar los servicios en la inyección de uso de ViewModel, es decir, pasar el servicio al constructor de ViewModel o establecer una propiedad.

Intento crear una estrategia para manejar formularios emergentes para usar en cualquier parte de mi aplicación. Mi comprensión hasta ahora es que necesitaré un solo UserControl en la raíz de mi MainWindow. Esto estará ligado a su propio ViewModel que manejará los mensajes que se envían dentro de la aplicación.

Estoy usando MVVM Light, y soy bastante nuevo en la clase de Messenger .

Imagine un escenario Maestro / Detalles, donde una lista de objetos está contenida dentro de un ListBox . Seleccionar uno de estos elementos y hacer clic en un botón Editar mostraría un UserControl que cubre toda la pantalla. El usuario puede editar el elemento seleccionado y hacer clic en Aceptar para confirmar el cambio.

Quiero que el UserControl que se abre sea "genérico" de forma que pueda arrojar alguno (probablemente un ViewModel) ... para que represente ViewModel a través de DataTemplate y maneje todos los cambios de objeto. Al hacer clic en Aceptar se devolverá la llamada a la clase de envío y persistirá el cambio como antes.

Algunas situaciones en las que esto sería útil son ...

  1. Mostrar mensajes de error sin la entrada de usuario requerida (que no sea OK para cerrarlo)
  2. Mostrar un formulario de edición para un elemento de datos
  3. Diálogos de confirmación (muy parecido a un MessageBox estándar)

¿Alguien puede proporcionar ejemplos de código sobre cómo puedo lograr esto?


Desde la perspectiva de un desarrollador que ingresa para ''mantener'' ese código genérico, suena como un dolor. De acuerdo con lo que describió, le daría al formulario y al diálogo el mismo modelo de vista y crearía una plantilla XAML específica para el diálogo que desea mostrar.


Recientemente comencé a aprender MVVM para una aplicación WPF que estaba creando. Utilicé este article como base para mostrar diálogos. Si descarga el proyecto de muestra, en realidad es un buen método desacoplado, está bien abstraído y tiene una vista que pasar una instancia de un modelo de vista. Lo extendí un poco por mis propios medios, también usé el WPFExtendedToolkit MessageBox para advertencias, errores, etc. porque el MessageBox win32 estándar es fugly.

Con respecto a los formularios dinámicos, querrá investigar ItemsControl, y en su ViewModels tendrá una Colección de elementos de datos que el usuario deberá editar para que ItemsControl se vincule. Tengo un diálogo para editar acciones y sus parámetros en un diseñador de sistemas de flujo de trabajo donde la lista de acciones de diálogo era totalmente dinámica. Esto se hizo al exponer una colección de mis elementos con sus tipos de datos para poder usar un DataTemplateSelector para seleccionar DataTemplates que contenía los tipos de controles correctos, es decir, un tipo de datos de DateTime mostraba un DatePicker.

Espero que ayude