在将并发冲突传达给您的应用程序层时，是否可以使用同样遵守Command-Query Separation原则的异常，或者是我们拥有的最佳机制（支持异常的语言）？
在我的应用程序的内容中，我有乐观的锁定逻辑，当我调用某些高级方法时执行几层，例如（就我而言，我正在使用自定义数据访问层，但我当然愿意听听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的分类法中，他们是否有资格成为exogenous exceptions？
答案 0 :(得分：1)
在我看来，例外是传达这类错误的最佳方式。我认为你的解决方案非常正确，因为你抛出了一个特殊的异常，你可以在表示层捕获它。表示层可以使用该异常中的信息显示给用户。
虽然例外是最好的方式，但创建良好的用户体验可能非常困难。最简单的方法是告诉用户存在冲突，并选择是否要丢失更改或者想要覆盖新的更改。当您想要显示冲突或让用户选择要覆盖哪些值以及哪些值不被覆盖时，它会变得很难。或者至少，以通用方式执行此操作非常困难。您可能需要一个特定的接口来解决系统中可能发生冲突的每个屏幕的此类冲突。
在我所使用的系统中，我们几乎没有捕获这些异常以便向用户显示。我们大多试图通过改变它背后的过程来防止这些冲突的发生。当然，这完全取决于您的应用程序类型以及业务运作方式（或者喜欢工作）最适合的解决方案。