2008-11-24 12 views
7

Estoy implementando MVP/M-V-VM en WPF y estoy teniendo buena suerte hasta el momento. Sin embargo, no veo cómo este modelo admite la implementación de cuadros de diálogo Modal. He derivado mi trabajo de Crack.NET (http://www.codeplex.com/cracknetproject) para aprender cómo funciona esto.Modelo-Vista-Presentador y cuadros de diálogo Modal .... ¿Cómo?

Tengo una vista ShellView (que es solo XAML) que tiene un menú en ella. El menú se une a un comando en ShellModelView que dice "EditPreferences".

ShellModelView implementa el ICommand para EditPreferences y aquí queremos poner un cuadro de diálogo para permitir al usuario editar las preferencias de la aplicación.

Varios problemas aquí: 1. ShellModelView no tiene una referencia al ShellView para originar correctamente el diálogo. ShellModelView es el DataContext de ShellView, pero no veo una retro-referencia configurada. 2. ShellModelView no debería cargar interfaz de usuario explícita de todos modos. Entonces, ¿cuál es el modelo de interacción adecuado aquí? 3. ¿Cómo construyo mi PreferencesDialog para que esté adecuadamente separado entre la lógica y la vista también? PreferencesDialog en sí necesita ser una ventana para que pueda llamar a ShowDialog, pero eso significa que necesita una referencia a la ventana (por ejemplo, ver) para crear una instancia. Idealmente, debería ser capaz de probar el código/validación unitaria dentro de PreferencesDialog sin crear una instancia de la vista (¿usando una vista simulada quizás?).

Respuesta

1

Necesitará un controlador en su caso. El controlador debe estar a cargo de mostrar la ventana de diálogo de preferencias.

Como puedo imaginarlo, el controlador debería ser responsable de crear ShellModelView y vincular el DataContext de la vista a él. El controlador también debe ser responsable de manejar la ejecución de comandos de EditPreferences. En la lógica de ejecución, el controlador creará un nuevo PreferencesDialog y su correspondiente modelo de vista.

Puede encontrar patrones similares en Prism si aún no lo ha hecho. También puede reutilizar el DelegateCommand proporcionado allí :)

6

Quizás esta no sea la manera adecuada de verlo, pero este es el enfoque que tomo con M-V-VM en WPF. La apertura de ventanas y cuadros de diálogo o una vista "EditPreferences" son funciones específicas de UI. Si tuviera que reescribir la interfaz de usuario completa reemplazando todas las vistas, puedo terminar combinando la vista "EditarPreferencias" con otra vista y, por lo tanto, nunca quiero abrirla en otra pantalla. Si esto estuviera relacionado con ViewModel, sería difícil moverse. En esta situación particular, tendría un botón o elemento de menú en mi "ShellView" que crea una nueva instancia de mi vista "EditPreferences", y luego pasa en el modelo de vista "EditPreferences" que puede provenir de una propiedad en mi "ShellViewModel" ", o tal vez mi vista" EditPreferences "ejemplifica el propio ViewModel.

Aquí es una pregunta similar sobre de manera que básicamente dice lo mismo: M-V-VM Design Question. Calling View from ViewModel

1

Tener la PreferencesDialog implementar una interfaz que es una de las propiedades del comando EditPreference. El comando interactuaría con el diálogo a través de la interfaz. Para la prueba unitaria, el objeto simulado implementaría la interfaz en su lugar.

La clase de diálogo puede residir en la capa más alta.

+1

pensé que uno de los objetivos de MVVM es lograr no tener el modelo de vista sabe nada de la Vista (o diálogo en tu ejemplo)? De modo que cualquier cantidad de Vistas (o ninguna) puede estar usando un Modelo de Vista en cualquier momento. Tener su ViewModel configurado cosas en una interfaz de View un poco rompe eso. –

+0

No porque la interfaz aísla el comando de la implementación del diálogo. –

+0

Ese es el patrón de MVP. Al cambiar su interfaz de Vista sugerida se rompería el ViewModel, p. cambie la firma de un método o tipo de propiedad, BAM acaba de romper su ViewModel que tiene una dependencia en la interfaz. En MVVM, la vista 'observa' el ViewModel mediante enlaces. Hacer cambios en la Vista (por ejemplo, agregar controles) no requerirá cambiar las interfaces o incluso volver a compilar ViewModel. Lo bueno es que un solo ViewModel puede ser 'observado' por muchas Vistas. Vea el patrón Observer en el libro GOF y lea la sección de documentación de Prism 'Modelo de presentación' si le interesa más esto :) –

0

Mis 2 centavos es:

  1. Pase algún tipo de contrato viewfactory como parámetro del comando o inyectar un contrato viewfactory en el modelo de vista.El modelo de vista usará viewfactory para crear cualquier vista modal/no modal que necesite. Viewfactory también podría tomar como parámetro de su método Show/ShowModal un modelo de vista para mostrar. Además, viewfactory podría usar un datatemplate para mostrar cualquier viewmodal pasado como parámetro.

  2. Agregue una propiedad ShowViewModel al modelo de vista en cuestión. Un DataTrigger podría luego ver de esta propiedad y cuando es de un tipo particular mostrar la vista, etc.

Cuestiones relacionadas