asp.net - 在 ASP.Net 上每个 Web 请求创建 dbcontext 的成本

Question

我在我的 asp.net Web 应用程序中使用工作单元和存储库模式以及 EF6。 DbContext 对象在每次请求时都会被创建和销毁。

我认为在每个请求上创建新的 dbcontext 的成本很高(我没有做任何性能基准测试)。

在每个请求上创建 DbContext 的成本可以忽略吗？有人做过基准测试吗？

Answer 1

创建一个新的上下文非常便宜，在我的应用程序中平均约为 137 个刻度(0.0000137 秒)。

另一方面，保留上下文可能会非常昂贵，因此请经常丢弃它。

您查询的对象越多，最终在上下文中跟踪的实体就越多。由于实体是 POCOS， Entity Framework 绝对无法知道您修改了哪些实体，除非检查上下文中的每一个实体并相应地进行标记。

当然，一旦它们被标记，它只会对需要更新的实体进行数据库调用，但是当有大量实体被跟踪时，确定哪些需要更新是昂贵的，因为它必须根据已知值检查所有 POCOS 以查看它们是否已更改。

调用保存更改时进行更改跟踪的成本非常高，如果您一次只读取和更新一条记录，那么最好在每条记录之后处理上下文并创建一个新记录。另一种方法是卡在上下文上，这样您读取的每条记录都会在上下文中生成一个新实体，并且每次调用保存更改时都会慢一个实体。

是的，它确实更慢。例如，如果您要更新 10,000 个实体，一次将一个实体加载到同一上下文中，则第一次保存仅需要大约 30 个刻度，但后续每个实体将花费更长的时间，最后一个保存将花费超过 30,000 个刻度。相比之下，每次创建一个新上下文将导致每次更新一致的 30 个刻度。最后，由于卡在上下文和所有跟踪实体上的累积速度减慢，在每次提交之前处理和重新创建上下文最终只花费 20% 的时间(总时间的 1/5)!

这就是为什么您实际上应该只在上下文上调用一次保存更改，然后将其丢弃。如果您对上下文中的大量实体多次调用保存更改，则您可能没有正确使用它。显然，特殊情况是当您进行事务性操作时。

如果您需要执行某些事务操作，则需要手动打开自己的 SqlConnection 并在其上开始事务，或者需要在 TransactionScope 内打开它。然后，您可以通过传递相同的打开连接来创建 DbContext。您可以一遍又一遍地执行此操作，每次都处理 DbContext 对象，同时保持连接打开。通常，DbContext 会为您处理打开和关闭上下文，但如果您向它传递一个打开的连接，它不会尝试自动关闭它。

这样，您就可以将 DbContext 视为跟踪打开连接上的对象更改的帮助程序。您可以在同一连接上创建和销毁它任意多次，您可以在其中运行事务。了解幕后发生的事情非常重要。