我有一组坐在队列中的服务(非WCF)。当消息到达时,典型服务会进行一些计算,并将零个或多个结果消息吐出到其输出队列。除了主要功能外,每项服务都有一些内务处理逻辑,如身份验证/审计/记录/状态跟踪,确切的步骤和服务之间的顺序有所不同。这就是管道概念进入图片的地方。
我对最终设计的设计不满意,并寻找简化设计的方法。我应该在CCR端口后建模吗? ASP.NET管道? AOP?还有什么吗?
我目前的设计如下:我有一个IMessageHandler<TMessage>
接口和大约15个实现,它们使用IoC以6种独特的方式链接在一起。接口定义了单个方法 Handle(TMessage msg),因此每个实现都可以在将消息传递给菊花链中的下一个处理程序之前和之后执行某些逻辑。
这个问题是:很难记住每个实现的确切内容以及它们为这个特定服务链接这种特定方式的原因。另一方面,将每个方面都放在自己的类中可以更好地分离关注点,从而更容易进行单元测试。
想法?我能看到的任何好的管道模式?我可以用作参考的任何好的管道实现吗?或者我应该JFHCI?
答案 0 :(得分:2)
我使用你经常选择的设计,而不是IoC。
听起来你有一个“文档”问题。代码没有很好地解释它的作用。我可以看到这个问题的几个解决方案。
首先,您可以对代码进行大量评论。这通常是一种气味,并且在很大程度上取决于实施。您还可以通过以特定方式命名IoC配置来就地发表评论。
其次,您可以创建一堆对象。例如,如果有三个对象倾向于一起运行,则可以创建一个“AuthorizeAndAudit”类,该类委托给其他对象(可能是使用IoC和“插件系列”构建的,或者是容器调用的任何对象,如果支持的话)。这更好地将对象的意图联系在一起。我倾向于有一个IMessageHandler的集合,它也实现了IMessageHandler并且自己做了一个foreach。
第三,您可以分离出接口。听起来您可能只是因为它们包含链中不同部分发生的操作而分割对象。您可以为身份验证创建一个接口(或共享接口上的方法),一个用于审计等。您的对象可以在这些接口上实现这些接口。由于定义了接口的顺序(调用Auth然后审计等),您的对象可以处理链中的多个步骤(最终得到一个链链),而不需要拆分成单独的类。你甚至可能有一个对象,比如一个日志跟踪器,它在每个步骤被调用时都位于所有链和日志上。
除此之外,您开始涉及更复杂的事情,例如工作流程,Windows Workflow可能是一个值得关注的好地方。
答案 1 :(得分:2)
我经常编写类似于你描述的代码。为了清楚地表达代码的意图,我添加了一层“语法糖”,它组成了将在运行时执行应用程序工作的对象,并且还清楚地表达了最终对象图的作用。
史蒂夫弗里曼和我写了一篇关于我们在Java中用来构建这层语法糖的技术的论文:http://www.jmock.org/oopsla2006.pdf。我在C#和其他Algol系列语言中使用了相同的技术并构建了相当复杂的“领域特定嵌入式语言”,包括用于描述金融市场模型,分布式系统架构,通信协议栈,游戏中的精灵行为等的嵌入式语言。上。