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完全相同）。我希望能够反映AppDomain并找到所有实现IHandle的类并将它们注册到容器中，然后注册一个类型为T的MessageHandlerAdapter。

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

Answer 1

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

我见过许多人试图围绕某些工具编写抽象层的实例。主要是案例是日志记录和ORM框架。现在，当他们这样做时，人们就有了良好的愿望。他们希望“能够轻松切换库X”。不幸的是，由于几个原因，这是一个坏主意

不相容的概念。在您的示例中，您可能会提取出NSB Saga超时的概念。然而，无法保证这个概念在理论上的“图书馆转向未来”中的行为方式相同，或者概念将存在。通常这些“抽象层”最终成为单个库的直接映射，并且根本不可移植。
增加了复杂性。您将为解决方案添加大量复杂性。
样品无法使用。当你查看图书馆的样本时，你需要“将你的地图”映射到你的抽象层
进入障碍。虽然加入您团队的新开发人员可能已经使用了有问题的库，但他们将无法理解您的包装器
与API抗争。没有设计过具有“能够提取通用实现”功能的库。因此，API会主动打击您执行此活动。
调试。额外的层将使调试解决方案变得更加困难
性能。通常，更多的代码是更慢的代码。通常这些抽象层也需要使用反射......
支持。您将更难获得拥有该库的人员的支持，因为很难记录您与该库的交互方式。
正在进行的更改。每次有问题的库添加或更改API时，您必须先添加映射代码，然后才能在解决方案中利用该功能。
文档。通常需要花费大量的人力来为图书馆创建文档。对您而言，将抽象的文档提升到该级别将是一项重大的工作。

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

以下是Ayende关于抽象邪恶的一篇有趣文章。其中大部分适用于此方案http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer引用

...尽量避免不必要的复杂性...添加额外的抽象层通常只会使它变得困难。

包装NServiceBus.IHandleMessages

1 个答案: