C#最佳实践:集中事件控制器与否

我有一个应用程序,它由几个不同的程序集组成,其中一个程序集包含类所遵循的各种接口,以及类通过程序集边界进行通信.有几个类触发事件,有几个对这些事件感兴趣.

我的问题如下:实现某种中央EventConsolidator是一种好的做法吗？这将是高度耦合的,因为它需要知道抛出事件的每个类(或至少是接口),并且事件的每个消费者都需要具有对EventConsolidator的引用才能订阅.

目前我的情况是A级知道B级(但不是C级),B级知道C级等等.然后,如果C触发事件B需要将其拾起并触发自己的事件以便A响应.这些类型的链可能会变得很长,并且B可能只对事件感兴趣才能传递它.我不希望A知道C,因为这会破坏封装.

在这种情况下,有什么好的做法？集中事件,或者咧嘴笑,并在每个中间阶段定义事件？或者做出决定的标准是什么？谢谢!

编辑:这是另一个问题基本上是同一件事.

您可以将事件本身放在一个接口中,这样A不需要直接了解C,而只需知道它有相关事件.但是,也许你的意思是A的实例没有看到C的实例......

我会试着避开集中的事件系统.如你所说,它可能会使测试更加困难,并引入了紧耦合.

一个值得了解的模式是使事件代理变得简单.如果B仅公开事件以将其代理为C,则可以执行以下操作:

public event FooHandler Foo
{
    add
    {
        c.Foo += value;
    }
    remove
    {
        c.Foo -= value;
    }
}

这样它代理订阅/取消订阅而不是提升事件的行为.当然,这对GC的资格有影响 - 根据具体情况,这可能有益或无益.值得思考的是.

您可以尝试使用NInject或Unity应用程序块的事件代理.

这允许您,例如:

[Publish("foo://happened")]
public event EventHandler FooHappened;

[Subscribe("foo://happened")]
public void Foo_Happened(object sender, FooArgs args)
{ }

如果通过容器创建了两个对象,则事件将自动连接.