消息处理的管道模式

3
我有一组服务(非WCF),它们坐在队列上。当消息到达时,典型的服务会进行一些计算,并将零个或多个结果消息输出到其输出队列。除了其主要功能外,每个服务还具有一些管理逻辑,如身份验证/审计/日志记录/状态跟踪,确切的步骤和顺序在这些服务之间略有不同。这就是管道概念的出现。
我对我们最终采用的设计不满意,正在寻找简化它的方法。我应该模仿CCR端口?ASP.NET管道?AOP?还是其他什么?
我的当前设计如下:我有一个IMessageHandler接口和大约15个实现,使用IoC以6种独特的方式链接在一起。该接口定义单个方法Handle(TMessage msg),因此每个实现都可以在将消息传递给下一个处理程序之前和之后执行一些逻辑。
问题在于:有点难记住每个实现确切地做了什么,以及为什么它们以这种特定的方式链接到这个特定的服务。另一方面,让每个方面坐在自己的类中可以更好地分离关注点,因此更容易进行单元测试。

有什么好的流水线模式可以参考吗?有哪些不错的流水线实现可以作为参考?或者我应该JFHCI


类是否适合于功能组或具有某些继承依赖关系?这是一个可视化问题,而不是实现问题吗?也许您可以使用WF作为管道容器? - yieldvs
@yieldvs:不,也许吧。我有讨厌WF的理由,但还是谢谢。 - Andriy Volkov
2个回答

2

我经常使用您选择的设计,但并非总是使用IoC。

听起来您可能有一个“文档”问题。代码没有很好地解释其功能。我可以看到这个问题有几个解决方案。

首先,您可以大量注释代码。这通常是一种不好的做法,取决于具体实现。您还可以通过以特定方式命名IoC配置来在原地进行注释。

其次,您可以创建对象集合。例如,如果有三个对象经常一起运行,您可以创建一个“AuthorizeAndAudit”类,该类委托给其他对象(可能使用IoC和“插件系列”或容器支持的任何其他方法构建)。这更好地结合了对象的意图。我倾向于拥有一个IMessageHandler集合,它也实现IMessageHandler并对自身执行foreach。

第三,您可以将接口分离。听起来您可能有这样一种情况,即仅因为它们包含在链的不同部分中发生的操作而将对象拆分。您可以为认证创建一个接口(或共享接口上的方法),为审核创建一个接口等。您的对象可以实现其中一个或多个接口。由于接口顺序已定义(调用Auth然后Audit等),您的对象可以处理链中的多个步骤(您最终会得到一系列链),而无需拆分成单独的类。您甚至可能有一个对象,例如日志跟踪器,它位于所有链上并在每个步骤被调用时记录日志。

除此之外,您开始进入更复杂的流程,Windows Workflow可能是一个好地方。


我认为上面的第二个选项被称为组合模式:http://en.wikipedia.org/wiki/Composite_pattern - Brian Low

2
我经常写与您所描述的类似的代码。为了使代码意图清晰,我添加了一层“语法糖”,在运行时组合执行应用程序工作的对象,并明确表达最终对象图的作用。
Steve Freeman 和我撰写了一篇关于我们在Java中使用这些语法糖构建技术的论文: http://www.jmock.org/oopsla2006.pdf。我已经在C#和其他Algol系列语言中使用了相同的技术,并构建了相当复杂的“特定领域嵌入式语言”,包括用于描述金融市场模型、分布式系统架构、通信协议栈、游戏中精灵行为等等。

正确的链接是http://www.jmock.org/oopsla2006.pdf。 这篇论文似乎是关于构建流畅接口的,我猜你是在建议我这样做,以确保我的代码更有意义。谢谢! - Andriy Volkov
是的,这就是我建议的。我已经更正了链接。对于那个笔误我很抱歉(现在时间有点晚了!)。 - Nat

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接