error-handling - 在多层架构中执行批量操作时处理错误和反馈

Question

假设您有一个可以跨多个对象执行某些操作的业务逻辑方法。也许您想调用一个彩票号码挑选网络服务，为从列表中选择的每个人调用一次。在 Java 中，代码可能如下所示:

Set<Person> selectedPeople = ... // fetch list of people
for ( Person person : selectedPeople ) {
    String lotteryNumber = callLotteryNumberWebService( person );
    // ...
}

请注意，彩票号码 Web 服务可能会产生副作用，例如记录此人已请求彩票号码(可能会向他们的帐户收费)，因此即使 Web 服务调用对一个人失败，也可能对其他人成功。此信息(彩票号码)将需要反馈到更高级别( View )。

如果这是发生单个操作的情况，则业务逻辑方法可以返回单个值(例如，彩票号码)或抛出带有任何失败细节的异常。但是对于批量操作，有可能一些操作成功而一些操作失败。

这似乎是许多应用程序中都会出现的一种问题，应该有一种干净的方法来处理它。那么，将这种类型的信息从业务逻辑层反馈到应用程序中的另一层(如 View )的最佳方式是什么，最好是以可重用于不同类型的数据和操作的通用方式？

Answer 1

这个问题突出了异常处理、事务和想法的正确使用之间的重要区别 工作流“补偿”当正确说明时，这就是提问者试图达到的目的:

This seems like a type of problem that would occur in many applications and there should be a clean way to handle it.

这是一个常见问题，首先是您当前尝试的事务方法的一些背景知识:

数据交易最初是根据复式记账法建模的——一个贷方和相应的借方必须一起记录或根本不记录。随着事务变得比这更大，它们变得越来越难以正确实现，并且更难处理失败。当您开始跨系统边界执行单个事务的想法时，您很可能会错误地处理它。它可以完成，但需要复杂且必然具有更高延迟的事务协调器。在一定规模上，交易是错误的心态，补偿开始变得更有意义。

这是您返回并查看业务实际操作的地方。一笔大笔交易很可能不是商务人士所看到的。通常他们会看到一个步骤已完成，并且根据后续结果，可能需要采取不同的行动来弥补。这就是工作流的想法和 赔偿进来。 Here's one introduction to those concepts

例如，如果您从亚马逊订购一本书，他们可能不会在您的购物车中“锁定”记录，甚至在订单确认时使用严格的交易来确定该书是否仍有库存。他们无论如何都会把它卖给你，并在可能的时候发货。如果他们在几周内没有设法将其入库，他们可能会向您发送一封电子邮件，告诉您他们正在努力满足您的需求，您可以继续等待他们入库，或者您可以取消您的订单。这称为补偿，在许多实际业务流程中是必需的。

最后，这一切都没有什么特别之处。预计这会发生并使用正常的控制流。您不应该在此处使用您的语言的异常处理功能 ( good rules for when to throw an exception)。您也不应该依赖工具特定(WCF？)机制来查看或处理服务实现中发生的异常。传达故障应该是您的数据契约(Contract)(故障契约(Contract))的正常部分。

不幸的是，通过“干净的方式来处理它”没有设置可以神奇地处理它的标志，您必须继续分解问题并处理所有产生的部分。希望这些概念能够将您与其他人在处理此问题时所做的事情联系起来。

概括:

您的问题已经超出了事务的概念-> 研究工作流补偿。

祝你好运 -