问我的简单API的命令链/责任模式。好主意？

EN

命令链模式的思想是构建一个处理程序链，并沿着这个链传递一个命令，直到其中一个处理程序处理该命令。这种行为通常出现在事件处理中，例如，UI按钮中的单击事件在UI元素的层次结构中气泡，直到到达一个附加了相应处理程序的元素为止。然后，这个处理程序可以决定它是否处理该命令--实际上结束了事件处理--在这种情况下，事件将沿着链进一步传播。

现在让我们假设我们为您使用该模式的web。在我看来，您所描述的是一个经典的CRUD(L)接口，您的操作是(创建、读取、更新和删除)的一个子集。你说你有删除请求，我假设你也想要某种更新请求。让我们进一步假设您为这类请求编写了相应的处理程序hupd和hdel。按照命令链模式，然后构建链赫德尔湖来处理对API的请求。所发生的情况是，传递到链中的每个更新请求都由hupd立即处理，而每个删除请求都被hupd拒绝并传递给处理它的hdel。此行为显示了操作和处理程序之间的固定映射，这实际上使链变得不必要。(事实上，由于每次删除请求的检查和传递，链甚至会降低系统的性能)。这一切为什么要发生？因为没有两个处理程序负责处理具有相同操作类型的不同子集的请求。这里真正想要的是一个直接映射“更新”=> hdel，“删除”=> hdel“和一个dispatcher，它接收各自的请求并直接将它们传递给相应的处理程序。如果有动态注册表保存映射，则这种设计对于新的操作仍然是可扩展的。

现在您可以说，您希望有不同的处理程序，例如，删除A和B类型的元素，这为具有相同操作类型的请求子集提供了处理程序。但是，在处理程序和元素类型之间还有一个直接和固定的映射，也就是说，您可以根据目标元素类型重复分派请求。这为您提供了一个两级调度，在最坏的情况下，使用命令链，您将通过操作编号乘以元素类型的处理程序传递请求。

结论:我不建议使用命令链模式来实现这种API.要使模式具有价值，您需要一个场景，其中您希望动态添加和删除处理程序，以及处理程序实际处理事件的条件不能通过常量的简单映射来表示。

我不建议使用单一方法来处理所有请求操作。理想情况下，您应该使用DELETE来处理delete操作，从而帮助您拥有一个API，该API能够准确地告诉API的所有内容，以及POST、GET等等。

我建议您首先定义API作为起点。

1. 删除仪表板-> http://domain.com/dashboard/itemId中的项-删除操作
2. 刷新项-> http://domain.com/dashboard/itemId - Get操作

要知道，API是不言自明的，它将给出您想要做的事情以及维护方面的帮助的清晰图片。

在您的控制器中，您可以检测到操作，然后为每个操作调用相应的服务来执行操作。COR可能不是一个好的选择，因为它不适合这里。

首先，请注意这个问题拼写错误，因为命令链模式与公共API无关，而是与其内部的服务器端实现有关。

也就是说，指挥链模式非常适合你的需要。由于API是用新的操作和/或元素进行扩展的，所以可以将新的处理程序添加到链中以实现新的行为，而无需修改现有的行为。