7

我被要求开发一个层，该层将充当通用总线，而不直接引用 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。

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

4

1 回答 1

42

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

我见过很多人试图围绕某些工具编写抽象层的例子。大多数情况是日志记录和 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引用

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

于 2013-01-17T22:52:50.767 回答