design-patterns - command pattern c#
Confusión sobre los patrones de Message Bus/Command Dispatcher (2)
Generalmente, un bus de mensajes (o un despachador de eventos estándar) puede tener muchos suscriptores para diferentes tipos de mensajes / eventos.
Un bus de comando generalmente distribuye comandos a exactamente 1 manejador, similar a un enrutador que resuelve rutas a los controladores.
Recientemente he estado leyendo mucho sobre mensajes distribuidos y patrones asociados. Utilicé algunos de ellos soportados por las herramientas como por ejemplo NServiceBus .
Muchos de esos patrones se describen en internet. Algunos de los que recientemente leí fueron:
- Agente de mensajes: http://msdn.microsoft.com/en-us/library/ff648849.aspx
- Bus de mensajes: http://msdn.microsoft.com/en-us/library/ms978583.aspx
- Patrones de mensajería en SOA: http://msdn.microsoft.com/en-us/library/aa480027.aspx
- La publicación de Udi Dahan sobre las diferencias: http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences/
Si el uso de herramientas como NService Bus permite hacer muchas cosas sin pensar mucho en los problemas de infraestructura, surgieron algunas preguntas cuando intenté implementar un Message Bus básico y un controlador de comandos. De hecho, cuando se trata de estos patrones, no puedo ver muchas diferencias entre ellos.
No pegaré el código porque es demasiado largo, pero encontré dos publicaciones de blog que describen bastante bien la idea de implementación de la que me gustaría hablar.
- Bus de mensajes: http://brentedwards.net/2010/04/13/roll-your-own-simple-message-bus-event-aggregator/
La idea es simple, el bus de mensajes rastrea a los suscriptores y envía los mensajes a diferentes suscriptores si están interesados.
- Controlador de comandos: http://weblogs.asp.net/shijuvarghese/archive/2011/10/18/cqrs-commands-command-handlers-and-command-dispatcher.aspx
Es bastante similar al bus de mensajes. El bus de comando invoca los controladores de comando para un tipo de comando dado.
Así que en ambos casos hay similitudes.
¿Cuáles son las diferencias y los beneficios reales utilizando un patrón que otro (no estoy hablando de herramientas de soporte)? ¿Qué me estoy perdiendo?
La segunda pregunta es. ¿Es valioso el bus de mensajes sin las herramientas de soporte? No me veo a mí mismo para impulsar el apoyo a todos los arrendatarios por mi cuenta.
Lo siento por una pregunta larga y confusa, pero no dude en pedir más detalles.
Woah, será difícil dar una respuesta más completa o más creíble que la MSDN a la que te conectaste, así que vamos por más conciso.
Un Bus de mensajes se ocupa de la comunicación . Ni siquiera requiere que la comunicación sea entregada es un comando o no. Tampoco le importa lo que es la carga útil. Es "tipo agnóstico". La principal preocupación del bus de mensajes es simplemente hacer un seguimiento de quién debe obtener cada comunicación (pub / sub). Una ventaja de este modelo es que admitirá una expansión futura para la que aún no tiene las especificaciones. Puede agregar un nuevo tipo de mensaje en el futuro y este modelo se complacerá en entregarlo. Es más probable que un bus de mensajes se distribuya fuera de su aplicación y quizás incluso fuera de su máquina (es decir, distribuido entre un grupo de 10 servidores).
Un modelo de controlador de comandos se ocupa de separar las acciones de la ejecución de un comando. Tradicionalmente (al menos en los idiomas que utilizo), los comandos estaban muy estrechamente asociados con los controles de la interfaz de usuario y sus eventos y el hilo de la interfaz de usuario. Con este modelo anterior, también fue difícil personalizar o ampliar el rango de comandos disponibles en su aplicación (por ejemplo, con una extensión DLL). El modelo de controlador de comandos separa las preocupaciones de la IU y la ejecución de comandos. Ahora tiene la flexibilidad de agregar fácilmente más manejadores de comandos y ejecutar comandos sin un evento de UI ( unidad que se puede probar ). Esto hace que el código sea más limpio, más modular y verificable. Es más probable que el controlador de comandos sea parte de su aplicación internamente. Es probable que cualquier extensión a su colección de comandos afecte a su aplicación y no a varias aplicaciones.
A Message / Command Broker le preocupa la conexión de sistemas independientes incompatibles o con un diseño diferente. Este es el caso de uso en el que desea que una aplicación interactúe con otra y no tenga el código fuente de una o ambas aplicaciones. Así que crea un corredor que recibe información de un lado y proporciona esta información del otro lado teniendo en cuenta las transformaciones necesarias para que estas dos aplicaciones se comuniquen. El ejemplo en MSDN es un sitio web de comercio electrónico que podría necesitar hablar con un procesador de pagos, una empresa de envíos y un sistema de contabilidad. Es posible que no pueda cambiar el código fuente de ninguna de estas aplicaciones (incluido el sistema de comercio electrónico). Tal vez el sistema de comercio electrónico requiera una interfaz IExamplePaymentGateway y su proveedor de pagos requiera una interfaz IDifferentPaymentAPI. ¿Tal vez una API está implementada en XML y la otra en JSON? Independientemente de las diferencias, su agente es responsable de hacer posible la conexión.
Como puede ver, todos ellos implican comunicarse de una manera u otra. Las líneas entre ellos pueden ser borrosas e incluso puede usar una combinación de varios de estos patrones para lograr su caso de uso particular.
Si bien nunca he usado NServiceBus, la mayoría de este tipo de bibliotecas simplemente intentan envolver los modelos abstractos / académicos en implementaciones específicas de lenguaje más concretas. A veces, esto le ahorra tiempo, a veces se queda atascado con una implementación deficiente de un colaborador de código abierto desconocido. Deberá evaluar su propio caso de uso y la idoneidad de las herramientas disponibles en su lenguaje de desarrollo preferido.