我有一组位于队列上的服务(非 WCF)。当消息到达时，典型的服务会进行一些计算并将零个或多个结果消息吐出到其输出队列。除了其主要功能外，每个服务都有一些内务管理逻辑，如身份验证/审计/日志记录/状态跟踪，具体步骤和顺序在服务之间有所不同。这就是管道概念进入画面的地方。
我对最终的设计不满意，并正在寻找简化它的方法。我应该模仿 CCR 端口吗？ ASP.NET 管道？面向对象？还有什么吗？
我目前的设计如下:我有一个 IMessageHandler<TMessage>接口(interface)和大约 15 个实现，它们使用 IoC 以 6 种独特的方式链接在一起。该接口(interface)定义了一个方法，Handle(TMessage msg)，因此每个实现都可以在将消息传递给菊花链中的下一个处理程序之前和之后执行一些逻辑。
这样做的问题是:很难记住每个实现的确切功能以及为什么将它们以这种特定方式链接到此特定服务。另一方面，将每个方面都放在自己的类中可以更好地分离关注点，从而更容易进行单元测试。
想法？我可以看看有什么好的管道模式吗？我可以用作引用的任何不错的管道实现吗？或者我应该 JFHCI ？
最佳答案
我经常使用您选择的设计，并不总是使用 IoC。
听起来您遇到了“文档”问题。该代码没有很好地解释它的作用。我可以看到这个问题的几个解决方案。
首先，您可以对您的代码进行大量注释。这通常是一种气味，并且在很大程度上取决于实现。您还可以通过以特定方式命名 IoC 配置来就地发表评论。
其次，您可以创建对象 block 。例如，如果有三个对象倾向于一起运行，您可以创建一个“AuthorizeAndAudit”类来委托(delegate)给其他对象(可能使用 IoC 和“插件系列”或您的容器调用它们的任何内容构建，如果支持的话)。这更好地将对象的意图联系在一起。我倾向于拥有一个 IMessageHandler 集合，它也实现了 IMessageHandler 并对其自身执行 foreach。
第三，你可以分离出接口(interface)。听起来您可能遇到这样一种情况，您只是因为它们包含发生在链的不同部分的操作而拆分对象。您可以为身份验证创建一个接口(interface)(或共享接口(interface)上的方法)，为审计等创建一个接口(interface)。您的对象可以实现这些接口(interface)中的一个或多个。由于定义了接口(interface)的顺序(调用 Auth，然后调用 Audit 等)，您的对象可以处理链中的多个步骤(您最终得到一连串的链)，而无需拆分为单独的类。您甚至可能有一个对象，如日志跟踪器，在调用每个步骤时位于所有链和日志上。
除此之外，您开始接触更复杂的东西，例如工作流，而 Windows Workflow 可能是一个不错的选择。
关于.net - 消息处理的管道模式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1060531/