nservicebus3 - 包装 NServiceBus.IHandleMessages

Question

我被要求开发一个层，该层将充当通用总线，而不直接引用 NServiceBus。到目前为止，由于支持不引人注目的消息，这并不太难。除了现在，我被要求为 IHandleMessages 提供我们自己的定义，并找到一种在接线期间映射它的方法。所以我在想这样的事情:

    public class MessageHandlerAdapter<T> : IHandleMessages<T>
{
    IUnityContainer container;

    public MessageHandlerAdapter(IUnityContainer container)
    {
        this.container = container;
    }

    #region IMessageHandler<T> Members

    public void Handle(T message)
    {
        var handler = container.Resolve<IHandle<T>>();
        handler.Handle(message);
    }

    #endregion
}

其中 IHandle 将是我们自己的定义(顺便说一下，它与 IHandleMessages 完全相同)。我希望反射(reflect) AppDomain 并找到所有实现 IHandle 的类并将它们注册到容器中，然后注册一个具有相同类型 T 的 MessageHandlerAdapter。

我的问题是我已经有将近 2 年没有使用 NServiceBus 了，我不记得在 NSB 管道中的哪里 Hook 这种功能。

Answer 1

您可能不会喜欢这个答案，但是...不要为您使用的工具编写抽象层。

我见过很多人试图围绕某些工具编写抽象层的例子。大多数情况下是日志记录和 ORM 框架。现在人们这样做的时候是出于好意。他们希望“能够轻松切换库 X”。不幸的是，这是一个坏主意，原因有几个

不兼容的概念。在您的示例中，您可能会提取出 NSB Saga 超时的概念。然而，不能保证这个概念在理论上的“将来要切换到的库”中的行为方式相同，或者这个概念会存在。通常这些“抽象层”最终会成为单个库的直接映射，并且根本不可移植。

增加了复杂性。您将为您的解决方案增加大量的复杂性。

sample 不起作用。当您查看库的示例时，您需要“映射到您的”到您的抽象层

进入壁垒。虽然加入您团队的新开发人员可能使用过相关库，但他们不会了解您的包装器

对抗 API。没有任何库的设计考虑到“能够提取通用实现”的功能。因此，API 将积极与您执行此事件进行斗争。

调试。额外的层会使您的解决方案更难调试

表现。一般来说，更多的代码是更慢的代码。也经常这些抽象层需要使用反射...

支持。您将更难从拥有图书馆的人那里获得支持，因为很难记录您与图书馆的互动方式。

持续的变化。每次有问题的库添加或更改 API 时，您都必须添加映射代码，然后才能在解决方案中利用该功能。

文档。通常，大量的工作时间已用于为图书馆创建文档。就您而言，将抽象的文档提升到该级别将是一项巨大的努力。

这一切都归结为时间。您现在正试图花时间抽象该工具。希望在 future 节省更多的时间。问题是如果您决定切换，您将花费更多的时间来创建和维护此抽象，而不是您将节省的时间。这应该是您对同事的回应。

这是 Ayende 的一篇有趣的帖子，讨论了抽象的弊端。其中大部分适用于这种情况 http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer报价

...try to avoid needless complexity... Adding additional layers of abstractions usually only make it hard.