¿Cómo puedo tomar ventaja de IObservable / IObserver para deshacerse de mi “objeto dios”?

Question

En un sistema Actualmente estoy trabajando, tengo muchos componentes que se definen como las interfaces y las clases base. Cada parte del sistema tiene algunos puntos específicos en los que interactúan con otras partes del sistema.

Por ejemplo, los datos preparando componente prepara algunos datos que eventualmente tiene que ir a la parte de procesamiento de datos, el componente de comunicaciones necesita consultar diferentes componentes para su estado para retransmitir hacia el exterior, etc.

Actualmente, pego estas partes del sistema entre sí utilizando un "objeto dios", o un objeto con conocimiento íntimo de las diferentes partes del sistema. Se registra los eventos más aquí y lanzaderas de los resultados a los métodos de ahí, crea un método de devolución de llamada aquí y devuelve el resultado de ese método por allí, y pasa muchas peticiones a través de una cola de subprocesos múltiples para el procesamiento, ya que "sabe" ciertas acciones tienen para funcionar en subprocesos STA, etc.

Mientras que su conveniente, Me preocupa que éste tipo sabe mucho acerca de cómo se ha diseñado todo el resto del sistema. Me gustaría mucho prefieren un hub más genérico que se puede dar ejemplos que pueden exponer a los eventos o métodos o devoluciones de llamada o que pueden consumir estos.

He estado viendo más sobre las características IObservable / IObserver del marco reactiva y que se están implementando en .NET 4.0 (creo).

¿Puedo aprovechar este patrón para ayudar a reemplazar mi "objeto dios"? ¿Cómo debo ir haciendo esto? ¿Hay recursos para el uso de este patrón para este propósito específico?

Answer 1

Parece que puede reemplazar su dios objeto con lo que MSDN describe aquí:

  

Para crear procesamiento de eventos complejos   (CEP) las aplicaciones que utilizan el Microsoft   StreamInsight plataforma, se crea   estructuras que definen los eventos,   objetos que producen y consumen la   eventos y plantillas de consulta que   contener la lógica de negocio necesaria para   procesar los eventos.

Nuestro equipo no se está moviendo a .Net 4.0 en el corto plazo (por desgracia). Así que eludido un dios objeto escenario mediante la construcción de un marco de encargo similar a lo que MAF / MEF ofrece. Esto creó una base de conocimientos difundidos a través de lo que Microsoft llama un adaptador . Cada adaptador sólo es responsable de su propio módulo, pasar los datos, eventos, etc. Hay un común operador que recibe los datos y eventos, procesos, y pasa de nuevo al adaptador de red correspondiente.

Mi comprensión de IObservable y IObserver presta yo creo que un dios objeto no ser necesario - en efecto, la creación de una base de conocimiento distribuido de lo que está pasando dentro de las diferentes partes. Una ventaja evidente para estas interfaces también parece ser que el comunicador intermedio (es decir, el adaptador) ya no es necesario. Por lo que la distribución del conocimiento es realmente en la clase derivada IObservable. Este modelo deriva intrínsecamente un hablador / respondedor relación -. Ninguna clase de mediación / arbitraje