¿Necesito un bus de servicio para el manejo de comandos asincrónicos simples?

Question

Mi sistema utiliza The Command Pattern con controladores separados.Mis comandos se ejecutan en un CommandService que actualmente maneja todos los comandos en proceso.

Tengo ciertos comandos que hacen al menos 1 de estas cosas que son operaciones lentas:

1. Envía un correo electrónico
2. Genera un PDF
3. Envía un fax
4. Interactúa con servicios web de terceros

Quiero que todos estos comandos se manejen fuera del proceso para que la interfaz de usuario sea más ágil.

¿Debo usar un bus de mensajería solo para estos comandos, o debería hacer que el controlador de comandos en proceso llame? BeginInvoke()?

Editar - Información adicional

El sistema tiene una pequeña cantidad de usuarios (tal vez 100 simultáneos en un día ocupado), por lo que la cola probablemente nunca será muy larga.Lo principal aquí es reducir la cantidad de tiempo que la interfaz de usuario permanece bloqueada al enviar un correo electrónico con un PDF adjunto (el comando en cuestión).Los empleados tienen que ejecutar ese comando muchas veces al día.

Con toda la situación en mente, creo que voy a seguir con BeginInvoke() por ahora por varias razones:

1. Se deberían tocar todas las interacciones de la interfaz de usuario para asegurarse de que se comporten como si el comando se hubiera ejecutado correctamente.El recordatorio de "debe enviar este documento" se encuentra en varios lugares de la interfaz de usuario y actualiza la página completa una vez que se envía el informe.
2. Estamos en la mitad de la temporada alta de mi cliente (hacen más del 50% de su negocio anual en el verano), por lo que no me parece prudente en este momento introducir una infraestructura completamente nueva cuya administración no estoy familiarizada. .

Pero sabiendo lo que sé ahora, en un sistema nuevo usaría un bus de servicio desde el principio para cualquier comando lento (prácticamente todos los sistemas necesitan enviar un correo electrónico) y diseñaría la interfaz de usuario para que los comandos puedan cambiarse más fácilmente de sincrónicos. al procesamiento asincrónico.En la implementación, eso básicamente significa que cada POST es AJAX y realiza una acción en la interfaz de usuario como si tuviera éxito.(Para ver un ejemplo de esto, consulte cómo Facebook maneja los comentarios).

Answer 1

Ambas soluciones tienen sus pros y sus contras.

• BeginInvoke es una solución increíblemente simple y su semántica es la misma que simplemente llamar a un controlador mediante un comando directamente.Pero esta solución depende de la infraestructura de subprocesos:números máximos de subprocesos, subprocesos congelados debido al acceso simultáneo a los recursos de IO, etc.
• MessageBus es una solución muy flexible y poderosa donde puede controlar todos los aspectos del proceso de manejo de comandos.Pero introduce otra capa de abstracción a su aplicación que sería una ingeniería excesiva en caso de que más simple signifique mejor.

Recomendaría estimar los requisitos de carga de su sistema, la cantidad de estas tareas en segundo plano, el factor de crecimiento, etc., y depende de eso para tomar una decisión.

Pero en mi opinión personal, introducir una solución de bus que se ajuste al 80% de los casos.Puede introducir una implementación de bus ingenua que será posible ampliar en las próximas iteraciones si es necesario.

Answer 2

Probablemente sea más una cuestión de confiabilidad lo que lo empujaría hacia un bus de mensajes.Verá, si su transacción original (la que realizó BeginInvoke) tuviera éxito y luego, a mitad de su invocación, el servidor fallara, su sistema no tendría la memoria que aún necesita para enviar un correo electrónico o generar el PDF. .

Un bus de mensajes podría revertir esa segunda transacción a una cola para que cuando el servidor se iniciara nuevamente, enviara el correo electrónico nuevamente.