2009-05-19 19 views
6

Estoy escribiendo una aplicación que escucha en una conexión de red, y cuando llegan algunos datos, responde de nuevo, y dependiendo de los datos entrantes, es posible que tenga que preguntar al usuario (mostrar el cuadro de diálogo) antes de responder de nuevo.¿Cómo obtener la entrada del usuario limpiamente desde la mitad del método del modelo en la arquitectura Model-View-Viewmodel?

No sé cómo hacer esto limpiamente en la arquitectura MV-VM: los eventos y el enlace a las colecciones observables son agradables si solo necesito actualizar la GUI en base a los datos entrantes, pero ¿qué sucede si realmente necesito una respuesta? usuario antes de responder de nuevo?

Y para empeorar las cosas, quiero hacerlo de forma síncrona, porque quiero que mi algoritmo de respuesta esté en un lugar, no particionado en múltiples devoluciones de llamada con responsabilidades inciertas de 'quién llama'.

Simplemente, algo así como

HandleMessage(Message msg){ 
    string reply; 
    if (msg.type == 1) { 
     reply = ... 
    } else { 
     string question = msg... 
     reply = ShowModalDialog(question); // MVVM violation! 
    } 
    sender.Send(reply); 
} 

pero no quiero llamar a la vista o el modelo de vista del modelo, ya que el modelo tiene que ser reutilizable y comprobable - No quiero hacer estallar los cuadros de diálogo en cada prueba, ¡y sería una violación de MVVM! No hay eventos (son, por lo que sé, de un solo sentido, y no tienen un canal hacia atrás para obtener respuesta al origen del evento) o enlaces de datos, ya que serían asíncronos.

¿Es esto factible? Esta es una pregunta que hice a varios propagadores de desarrollo impulsados ​​por pruebas, y hasta ahora, no obtuve una respuesta práctica. Sin embargo, la necesidad de una entrada adicional en el medio del procesamiento es bastante común.

Gracias!

EDITAR: esta es la lógica de la aplicación, por lo que claramente pertenece al modelo, y aunque en este caso no fue así, me gustaría saber la solución para los casos cuando realmente necesito la opinión del usuario en el medio de la empresa rutina lógica en el modelo.

Respuesta

3

Este es uno de esos problemas que MVVM no resuelve por sí mismo. Una solución sería usar un servicio para consultar al usuario y luego hacer que ViewModel use ese servicio.

En mi proyecto utilizamos PRISM, que además de proporcionar un marco de servicios también proporciona otras herramientas para facilitar el desarrollo de la GUI.

Here's una descripción de cómo funcionan los servicios en PRISM.

Específicamente en su caso crearía algún tipo de IOC, registraría un servicio de consulta con él, luego en el pase de ViewModel en el IOC y luego usaría el IOC para obtener el servicio de consulta, y lo usaría para consultar al usuario . ¿Mas trabajo? Por supuesto.Pero significa que puede reemplazar el servicio de consultas con otra implementación para probar simplemente reemplazándolo en el IOC.

MVVM + Services = Ultimate Power!

+0

+1 por explicarlo mucho mejor que yo. –

+0

Gracias, esto suena como una solución limpia, leeré los enlaces (¡gracias por ellos!) –

0

En realidad, no TODO pertenece a la lógica de la aplicación.

Parece que tiene 2 "vistas" diferentes. Está el inicial (los datos ingresan a través de la red) y el segundo (diálogo de confirmación).

El modelo necesita determinar que se debe mostrar una nueva vista, señalar la vista para mostrarla y luego responder a la entrada de esa vista.

No intente hacer todo en un solo paso.

+0

Estoy de acuerdo con la primera observación: sí, la vista inicial es solo la ventana de registro de la consola del servicio, y el cuadro de diálogo de entrada de datos se puede considerar como otra vista. Hovewer, el modelo es impulsado por algoritmos, y me parece bastante loco tener que particionar un aloritmo en partes llamadas de forma asíncrona por UI, y en algunos casos, no es realmente posible. Además, desde el punto de vista de la mantenibilidad, es mucho mejor tener un algoritmo en un método. Por lo tanto, la llamada a la GUI debe ser sincrónica. –

+0

Entiendo exactamente lo que quieres decir. He tenido que usar máquinas de estado en algunos lugares realmente irritantes. Aunque sé que no quieres ir allí, hay muchas posibilidades de que tengas que hacerlo. Si no, genial, pero tal vez quieras reflexionar, es probable que termines haciéndolo. Un cuadro de diálogo a menudo implica liberar el hilo. No estoy en desacuerdo con su punto de que es una locura :) –

1

No sé si esta idea está en estricta conformidad con los principios de MVVM, pero ... Encapsularía la funcionalidad de diálogo como servicio (a través de una interfaz). La implementación del servicio estaría en la capa UI, pero para fines de prueba solo "simularías" la interfaz.

Cuestiones relacionadas