克服实体框架中缺少ConflictMode.ContinueOnConflict实现的模式？

Question

Linq To SQL的DataContext在SubmitChanges上有一个重载，当抛出乐观并发异常时，它允许更新继续进行，并为开发人员提供了一种机制，可以在一个Try Catch块中解决冲突。

甚至WCFDataServicesContext的SaveChanges方法都有一个SaveChangedOptions.ContinueOnError参数，该参数至少允许您在发生错误时继续更新，并且无法解决冲突的更新，因此您以后可以查看它们。

（1）为什么ObjectContext.SaveChanges方法没有这样的选项？

（2）是否存在任何模仿Linq To SQL行为的更新模式？ 我在MSDN上找到的示例使它看起来好像在多个更新的情况下， 一个Try Catch块将带您回家。 但是，此模式不允许您分别调查每个冲突的更新：它只是提醒您第一次冲突，然后为您提供“一次清理表中的数据”的选项，以防止出现任何进一步的乐观并发异常，而无需您知道是否存在，以及您想对它们做什么。

Answer 1

为什么ObjectContext.SaveChanges方法没有这样的选项？

我认为最简单的答案是因为Linq-to-Sql，实体框架和WCF数据服务都是由不同的团队实现的，并且这些团队之间的内部沟通无法如我们所愿。 我在以前的答案中已经描述了较新的API中缺少的一些有趣的功能，但是我不认为这是缺少的功能-我将在答案的第二部分中对此进行解释。

WCF数据服务具有更多有趣的功能，这些功能也应该成为实体框架的一部分。 例如：

• 变更和查询拦截器
• 批处理多个查询和SaveChanges操作以单次调用服务器
• 异步操作 -这将以异步/等待实现的形式出现在EF6中

是否存在任何模仿Linq To SQL行为的更新模式？

有一种模式可以解决此问题，但您可能会不喜欢它。 EF的SaveChanges工作单元。 它要么保存所有更改，要么不保存任何更改。 如果您遇到的情况是，如果仅保留部分更改，则可能导致保存操作，而不是通过单个SaveChanges调用来处理。 每个原子更改集都应具有自己的SaveChanges调用：

using (var scope = new TransactionScope(...)) {
    foreach (var entity in someEntitiesToModify) {
        try {
            context.SomeEntities.Attach(entity);
            context.ObjectStateManager.ChangeObjectState(entity, EntityState.Modified);
            context.SaveChanges();
        catch (OptimisticConcurrencyException e) {
            // Do something here 

            context.Refresh(e.StateEntries[0].Entity, RefreshMode.ClientWins);
            context.SaveChanges();
        }
    }

    scope.Complete();
}

我认为之所以不存在该功能，是因为它不是通用的，并且如上所述，它与工作单元模式背道而驰。 假设这个例子：

• 您加载实体
• 您将新的从属实体添加到已加载实体的导航属性中
• 您在已加载的实体上进行更改
• 同时，其他人同时删除了您已加载的实体
• 您可以通过轻松的冲突解决方案触发SaveChanges
• EF会尝试将更改保存到主体实体，但由于数据库中没有要更新的实体，因此会发生冲突
• EF将继续，因为放松了冲突解决
• EF会尝试插入依赖实体，但会触发SqlException因为主体实体在数据库中不存在。 此异常将破坏持久性操作，并且您将不知道为什么它抱怨引用完整性，因为您有主体实体。 （由于上下文内部状态的不一致，这种插入甚至可能不会发生，并且EF会引发另一个异常，但这取决于EF的内部实现）。

这立即使解决冲突的整个放松变得更加复杂。 恕我直言，有三种解决方法：

• 根本不支持它。 如果需要基于每个实体的冲突解决方案，您仍然可以使用上面显示的示例，但是对于复杂的方案，由于复杂的方案难以解决，因此可能无法正常工作。
• 每次发生冲突时都要重建数据库变更集-这意味着要探索剩余的变更集，并从处理的持久性中排除与冲突实体及其关系等有关的所有实体。 有一个问题：EF无法从处理中排除任何更改的实体。 那会破坏工作单元的含义，我再重复一遍：放松冲突解决方法也会破坏工作单元的含义。
• 即使主体实体发生冲突，也让EF继续进行依赖。 这需要处理数据库异常并了解其内容，以了解异常是由于主体冲突还是由于其他错误（应立即使整个持久性操作失败）而引发的。 在代码级别理解数据库异常可能非常困难，而且它是每个支持的数据库特定于提供程序的。

这并不意味着不可能实现这种功能，但是涉及关系时，它需要涵盖所有场景，而且这可能非常复杂。 我不确定Linq-to-Sql是否可以处理此问题。

您总是可以对Data UserVoice提出建议，也可以签出代码并尝试自己实施。 也许我觉得这个功能太复杂了，很容易实现。