Creación de una estrategia de diálogo amigable MVVM

Question

Estoy tratando de 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 Messenger.

Imagina un escenario maestro/detalles, donde una lista de objetos está contenida dentro de un ListBox. Seleccionar uno de estos elementos y hacer clic en el 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 para ser "genérico" de una manera que pueda arrojar alguna (probablemente un modelo de vista) en ella ... para que acabe con el modelo de vista a través de un DataTemplate y manejar 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 que esto sería útil son ...

1. mensajes de error de pantalla sin intervención alguna del operario (que no sea en Aceptar para cerrarlo)
2. Display un formulario de edición de un elemento de datos
3. diálogos de confirmación (como un cuadro de mensaje estándar)

puede cualquier persona proporcionar cualquier ejemplos de código de cómo podría lograr esto?

Answer 1

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 de prestación de un servicio que muestra cuadros de diálogo hay dos enfoques diferentes que flotan cerca de:

1. Aplicación del DialogService en la vista (por ejemplo, véase la muestra http://geekswithblogs.net/lbugnion/archive/2011/04/13/deep-dive-mvvm-samples-mix11-deepdivemvvm.aspx 03).
2. La implementación de un componente de servicio que no está unido a la vista (por ejemplo, ver 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 del servicio ofrece. 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 a la vista.

Otra posible solución es usar mensajes para mostrar los cuadros de diálogo.

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 vincular los servicios en la inyección de uso de ViewModel, es decir, pasar el servicio al constructor de ViewModel o establecer una propiedad.

Answer 2

Recientemente comencé a aprender MVVM para una aplicación WPF que estaba creando, utilicé este article como base para mostrar los diálogos, si descarga el proyecto de muestra, entonces es realmente un buen método desacoplado, está muy bien abstraído y obtener una vista que pase 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.

En cuanto a las formas dinámicas, entonces querrá investigar el ItemsControl, y en sus ViewModels tener una colección de elementos de datos que necesitan ser editado por el usuario para el ItemsControl para unirse a. 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.

Esperamos que ayuda a

Answer 3

Desde el punto de vista de un desarrollador que entra a 'mantener' ese código genérico, que 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.