nolock/TransactionScope与快照隔离

首先，NoLock（和ReadUncommitted）非常危险。想想看，您之所以使用事务，主要是因为您希望数据保持一致。通过使用NoLock，您可以对数据进行脏读。比方说，在您的应用程序中，您很可能读取一半更新或一半插入的数据。您的应用程序（或用户）将根据不一致的数据做出决策。

如果你去公司，只是简单地问你的应用程序工作的数据是否不一致，我相信答案肯定是否定的。所以不要走这条路，我们已经走了，但最终没有结果。

现在是订单。据我所知，理论上不能保证它是否总是相同的顺序，但实际上可能会是（因为ORM通常只有一个算法来枚举实体和发现更改）。但这并没有真正的帮助，因为即使它以相同的顺序枚举实体（以便找到需要保存的内容），实体类型的数量也可能不同。比方说，在一种情况下是A和D，在另一种情况中是A、B、D，而在另一个情况中是A、C、D。现在，它可能取决于这些实体之间的关系。比如说，C取决于D，所以实际的顺序实际上是A，D，C，而不是A，C，D（即使在这里也没有指定它不会是D，C和A）。因此，转发此订单不是一种选择。为了确保订单，你唯一能做的就是在每一步之后调用.SaveChanges（），这很糟糕。

是的，您可以使用快照隔离级别（有两种，基本上是任何一种，请尝试快照读取提交）。它将显著减少系统中的死锁数量，但这种方法也有其自身的缺点。

为了或多或少地正确解决这个问题，我建议您在系统中明确定义事务边界。系统的哪个部分"拥有"哪些数据？哪些数据必须与其他数据保持一致？然后你可以说"只允许这些交易"answers"只允许我的系统的这一特定部分接触这些特定数据"。

这很难，尤其是在刚开始的时候，当你有一个庞大的数据库，读写混乱，到处都是。但它带来了更稳定、可控和可维护的系统。

顺便说一句，Udi Dahan有一篇有趣的博客文章：数据不一致、性能差或SOA——选择一个