问题标签 [chain-of-responsibility]

我的项目中有一个要求，我必须构建一个 Web 服务。该网络服务将执行以下操作：

1. 接受 XML 格式数据
2. 返回 XML 格式数据
3. XML 输入数据将有一个元素包含登录信息和另一个需要处理的元素数据。

现在我正在寻找一种设计模式，我可以在其中使 web 服务代码看起来整洁干净。因为网络服务必须做很多事情，比如。

1. 首先解析xml
2. 通过检查用户名和密码来验证请求
3. 从数据创建对象，然后将数据保存到数据库
4. 准备和将返回给客户端的 xml。

所以我有大约 4 个主要步骤，如果我在 .asmx.cs 文件中编写整个内容，肯定会使代码看起来很难看。

如果有人可以建议任何适合此的设计模式，以便代码在不久的将来易于维护。

由于这个模块要集成到我现有的项目中，因此有一些限制，比如我不能使用一些 3rd 方模块或 dll。

所以我一直在寻找类似单一职责原则、责任链或命令或装饰器模式或任何其他适合的 oop 概念的东西。

我已经搜索过，但还没有明白从哪种方式开始。

谢谢。

M。

我们需要构建一个解决方案来处理销售订单。处理是按顺序进行的：每个步骤都处理特定的任务：检查客户是否有信用，检查所需物品是否有库存等。

我们想到了使用责任链模式。

我发现了这篇古老但非常有价值的文章。它首先将 CoR 与模板模式进行比较。由于我们不关心耦合，因此它们似乎都有效。

我应该注意哪些缺点（或陷阱等）？

请有人用这些模式清理我脑海中的混乱：

• 指挥链
• 责任链

我见过两者相同的站点（命令链的示例与责任链相同），而其他站点则不同。

这是我对每个的理解：

指挥链：

我们将一个类称为 CommandChain，其属性包含一个“命令”列表，这些“命令”是实现相同接口的类的实例。假设他们都必须实现 onCommand(command, arguments)。

CommandChain 有 addCommand() 方法在其中注册新命令，runCommand() 接受命令名称及其参数。此方法应遍历命令列表，直到其中一个响应、执行相应操作并发送 ok。

责任链

正如我在某些站点中看到的那样，这几乎是相同的，但有以下区别：每个命令实例都将存储对下一个命令实例的引用，而不是让一个类存储要循环的命令列表。

那么，这种差异是否足以认为两种设计模式不同？

它们适用于哪些实际情况？

我正在尝试实现责任链模式，但似乎我遗漏了一些东西，因为在具体的类中，setnexthandler 没有设置下一个但总是相同的。我想我的错误出在 else statems next.setNextHandler(next); 中 processMalfunction() 方法中的具体类中。我认为第一个应该是 next.setNextHandler(Severity.Medium) 。如果您可以看一下，这里是代码。这是代码。

如果我有多个节点需要修改请求，那么仍然使用“责任链”设计模式是否是个好主意？还是应该只在只有一个（未知）节点专门处理请求时才使用这种模式？

IE：节点 2 和节点 3 都需要影响请求 (R)。因此，即使节点 2 处理了请求，我仍然想继续将请求向下传递到列表中的下一个处理程序

在我的应用程序中，我需要按一定顺序从数据库加载数据，例如加载所有客户，然后加载所有订单并加载产品等。但是，在一两种情况下，订单不同，也需要加载附加数据。

我最初的想法是我是否可以使用命令模式（使用加载命令方法）来实际加载客户、订单或产品，并使用责任链来捆绑命令。这是一个好方法还是我在这里过度工程？

任何示例代码都会非常有帮助。感谢您的任何建议

我正在研究设计模式。我不确定如何在 C++ 中实现责任链模式。我正在使用 Argo 工具从我的图表生成我的代码。

在此图中，Oracle 类是一个“客户端”。Oracle.cpp 构造函数方法具有下一行

在这里我得到“错误：'验证'没有在这个范围内声明”。我的问题：是否有必要创建从 Oracle 到验证的 UML 关系“依赖关系”？或者我将如何解决这个错误？

我理解责任链模式的概念，但也许我用错了。

我有几种类型的产品，并且我有一个控制器来控制为每种类型的产品显示的界面。用户选择产品类型，每个控制器负责显示相应的界面并与之交互。

为此，我使用了责任链模式，我认为这听起来不太好。我正在做的是创建一个控制器链，一旦我得到产品类型请求，我只需将它传递给控制器​​链并让适当的控制器实现请求。

但是在思考的时候，同样可以使用一个简单的工厂来实现，但是有很多条件语句。

您如何看待在这种情况下使用责任链？

我正在为我的管道使用责任链设计模式。我发现的一个问题是，随着我添加更多链，配置对象变得越来越大。本质上，我的配置对象正在变成一个巨大的单例。有没有有效的方法来处理这种情况？

细节：

我目前的设置是

我通过将配置对象传递给它来使用链。

配置对象具有处理程序所需的所有配置信息，因此随着我添加更多链而变得越来越大。

可能的解决方案：

在这篇文章中，最好的答案是使用依赖注入。

哪些设计模式可以应用于配置设置问题？

但是，我不确定如何在不大幅改变设计的情况下在责任链设计上使用依赖注入。

有人可以帮我解决这个问题吗？谢谢！

我必须在 C# 中实现流程图结构。我会将数据传递给第一个节点，它会检​​查一些数据项（布尔值），然后将数据路由到两个后续节点之一，依此类推。
基本的逻辑流程是这样的：

1. 节点 1

   • 如果颜色为红色，则转到节点 2
   • 否则转到节点 3

2. 节点 2

   • 如果权重为 10，则转到节点 4
   • 否则转到规则 5

3. 节点 3

   • 如果尺寸大，则转到节点 6
   • 否则转到节点 10

ETC

我一直在研究最初似乎解决了我的问题的责任链模式。但是，在我的大多数节点（处理程序）中，我需要有 2 个后续节点（真路径和假路径）才能潜在地调用。

查看 CoR 模式的实现，似乎有 NextHandler（Next Node）的概念，但没有 NextHandlerA 和 NextHandlerB - 例如。

因此，如果不是 CoR，哪种模式更适合解决这个问题。规则和顺序可能会经常变化。

谢谢你的时间。