2

在将并发冲突传达给您的应用程序层时，是否有替代使用也尊重命令查询分离原则的异常，或者异常是我们拥有的最佳机制（在支持异常的语言中）？

在我的应用程序的内部，我有乐观的锁定逻辑，当我调用某些高级方法时，它会向下执行几层，例如（在我的情况下，我使用的是自定义数据访问层，尽管我当然愿意听听 ORM 实现是如何做到这一点的）。应用程序与之交互的高级方法调用如下所示：

// 'data' is just a placeholder for multiple parameters, including something
// that contains row version information
void Customer.UpdateInformation(object data);

当其他人更新了他们正在处理的数据时，我需要能够告诉 Web 应用程序的用户。

我宁愿不从更改数据的方法中返回值。所以在过去，我抛出了异常（类似于 .NET 数据适配器 API，它在检测到冲突时会抛出DBConcurrencyException），但在某些常识上，并发冲突并不是异常的。它们是生活中的事实：应用程序工作流程中可预测的、预期的部分。在 Eric Lippert 的分类法中，它们是否有资格作为外生例外？

4

1 回答 1

1

在我看来，异常是传达此类错误的最佳方式。我认为您的解决方案非常正确，因为您抛出了一种可以在表示层捕获的特定异常。表示层可以使用该异常中的信息向用户显示。

虽然例外是最好的方法，但创造良好的用户体验可能非常困难。最简单的方法是告诉用户存在冲突，并选择他是想丢失他的更改还是想覆盖新的更改。当您想要显示冲突或让用户选择要覆盖的值和不覆盖的值时，这会变得很困难。或者至少，很难以通用的方式做到这一点。您可能需要一个特定的界面来解决系统中可能发生冲突的每个屏幕的此类冲突。

在我工作的系统中，我们几乎没有捕捉到这些异常以显示给用户。我们主要尝试通过更改其背后的流程来防止这些冲突的发生。当然，这完全取决于您的应用程序类型以及业务工作（或喜欢工作）的方式，哪种解决方案是最好的。

于 2010-06-01T15:55:00.450 回答