NServicebus / CQRS: Cómo manejar las cosas en la interfase de usuario?

Question

He estado leyendo el texto de Udi Dahan en [la separación comando de consulta y SOA] [1]. Pensando en cómo iba a usar esto en la práctica en un sistema actualmente estoy trabajando en suscitado algunas preguntas ...

---

1.

Considere la siguiente situación en la que tengo una aplicación cliente de WPF que permite al usuario editar una lista de entradas:

Se inicia la aplicación cliente. En el inicio, se suscribe al servicio de comandos que manejar y publicar los cambios de las entradas y la consulta a un servicio WCF para la lista completa de entradas. Después de recibir la lista de entradas, cualquier cambio (por otros clientes) que pueden haber sido publicados a los clientes hacen cola mientras estaba ocupado en espera de una respuesta del WCF se fusionan en la lista.

Ahora me parece que hay un (probablemente muy pequeño) de que el cliente se suscribe justo después de un comando responsable de un cambio fue manejado y que la consulta del servicio WCS se inicia justo antes del mismo cambio se ha comprometido con la base de datos . En esta situación, voy a terminar con datos incorrectos en mi cliente que no es (y nunca a entrar en) sincronizada con la base de datos (a menos que la aplicación cliente se reinicia). ¿Este problema realmente existe y si lo hace, ¿cómo debe ser manejado?

---

2. Mi segunda pregunta es acerca de cómo diseñar / implementar la interfaz de usuario:

Ahora el usuario quiere cambiar una entrada en la lista; Windows aparece, los datos se cambia y se pulsa el botón OK: enviamos un mensaje a nuestro controlador de comandos para manejar este cambio. El usuario espera ver una confirmación (la entrada en la lista cambia) o un error mensaje.

Ahora puedo tratar de manejar las cosas en la interfaz de usuario de una manera síncrona '(que el usuario pueda hacer una cosa a la vez, y dejar que esperar a que el éxito o el fracaso antes de que se le permite hacer cualquier otra cosa) de la siguiente manera :

1. Después de que el usuario presione OK, desactivar todos los controles por lo que no es posible su posterior edición.
2. Crea una saga con un tiempo de espera que espera a que ...? El mensaje de respuesta? La notificación publicada desde el servicio de comandos? ¿Ambos?
3. Cuando se recibe un mensaje de respuesta de los datos de la lista se cambia, los controles están habilitados y hemos terminado - o:
4. Un tiempo de espera se produce. El mensaje de comando está en la cola, por lo que con el tiempo se realiza el cambio, por lo que ¿qué hacer? Mostrar un mensaje al usuario ( "esto está tomando más tiempo de lo esperado ..."), permitirá a todos los controles y cambiar los datos en el cliente una vez que la notificación haya sido recibida desde el servicio de comandos? Pero lo que si se devuelve un error? El usuario puede haber empezado a hacer algo más (tal vez de editar otra entrada) y apareciendo un mensaje de error de una edición anterior intento no parece ser una buena idea.

Otro enfoque sería probablemente sólo desea enviar el comando y dejar que el usuario continúe con lo que le gusta hacer a continuación. Tal vez mostrar todos los comandos pendientes en una lista en la interfaz de usuario en algún lugar, con un indicador del éxito o el fracaso y la posibilidad para el usuario para mostrar el mensaje de error en caso de fallo. Teniendo en cuenta que los tiempos de espera son de esperar excepcional y que las respuestas que normalmente deben ser recibidos dentro de unos pocos segundos significaría que esta lista normalmente debe tener como máximo 1 comando destacada en ella .. Eso y el hecho de que no puedo recordar que he visto en mi vida una interfaz de usuario hacer las cosas de esta manera significa que no es probablemente una buena idea.

Y su pregunta es? ;)

Bueno, me pregunto acerca de cómo otras personas son la solución de esto en sus interfaces de usuario. Probablemente hay mejores maneras de manejar las cosas en la interfaz de usuario de las dos maneras tal vez no tan inteligentes que se me ocurrió?

Disculpas por el texto largo y gracias de antemano por sus respuestas.

[1]: http: // www.udidahan.com/2008/08/11/command-query-separation-y en SOA / "separación comando de consulta y SOA"

Answer 1

Para la pregunta número 1, la solución estándar para la consulta es crear un almacén persistente consulta de servidor que el cliente RPC-petición / respuestas contra.

Para la pregunta número 2, la respuesta es muy dependiente tanto en el dominio - los tipos de comandos, la naturaleza de la colaboración entre usuarios. Como una regla general, pensar en formas de cambiar la interfaz de usuario y / o los datos / manejo de los comandos de tal manera que los comandos casi nunca fallar (a menos que estamos hablando de usuarios maliciosos).

Espero que ayude.