CompositeWPF: EventAggregator: ¿cuándo usarlo?

Question

He estado buscando en el Composite Application Library, y es genial, pero tengo problemas para decidir cuándo usar el EventAggregator ... o mejor dicho, cuándo NO debo usarlo.

Mirando el ejemplo StockTraderRI, estoy aún más confundido. Están utilizando EventAggregator en algunos casos y eventos "clásicos" en otros casos (por ejemplo, en la interfaz IAccountPositionService).

Ya he decidido utilizarlo para la comunicación con una tarea de trabajo pesado, que debe ejecutarse en una cadena de fondo. En este caso, EventAggregator ofrece clasificación de hilos entre bastidores, por lo que no tengo que preocuparme demasiado por eso. Además de eso, me gusta el desacoplamiento que ofrece este enfoque.

Así que mi pregunta es: ¿Cuando comencé a usar EventAggregator en mi aplicación, por qué no usarlo para todos los eventos personalizados?

Answer 1

Esta es una buena pregunta. En Composite WPF (Prism) hay 3 maneras posibles de comunicarse entre partes de su aplicación. Una forma es usar Commanding, que se usa solo para pasar acciones desencadenadas por UI en el camino hacia el código real que implementa esa acción. Otra forma es usar Servicios Compartidos, donde varias partes contienen una referencia al mismo Servicio (Singleton) y manejan varios eventos en ese servicio de la manera clásica. Para la comunicación desconectada y asíncrona, como ya dijiste, la mejor manera es usar el Agregador de eventos (que sigue de cerca el patrón de Martin Fowler).

Ahora, cuándo y no usarlo:

1. usar cuando se necesita para la comunicación entre módulos. (por ejemplo, un módulo Tarea necesita ser notificado cuando una Tarea es creada por cualquier otro módulo).
2. Úselo cuando tenga múltiples receptores posibles o fuentes del mismo evento. Por ejemplo, tiene una lista de objetos y desea actualizarla siempre que se guarde o cree un objeto de ese tipo. En lugar de mantener referencias a todas las pantallas abiertas de edición/creación, simplemente suscríbase a este evento específico.
3. No lo utilice cuando solo tenga que suscribirse a eventos normales en el área de Presentación de modelos. Por ejemplo, si su presentador escucha cambios en el Modelo (por ejemplo, el Modelo implementa INotifyPropertyChanged) y su Presentador necesita reaccionar ante dichos cambios, es mejor que su Presentador maneje directamente el evento PropertyChanged del Modelo en lugar de desviar tales eventos a través del Agregador de eventos. Entonces, si tanto el emisor como el receptor están en la misma unidad, no es necesario "transmitir" dichos eventos a toda la aplicación.

Espero que responda a su pregunta.