ASP.NET DbContext实例注入但未使用 - 性能问题与否？

最新的方法说明了向MVC \ WebAPI控制器注入实例权限DbContext。它有一些专业人士，但我有一个问题还没有回答 - 性能的DbContext实例创建将不会被使用。ASP.NET DbContext实例注入但未使用 - 性能问题与否？

根据这个问题：What happens when i instantiate a class derived from EF DbContext?DbContext创建并不是那么便宜的操作（包括内存和CPU）。而且这两次糟糕的时候：

你的行动并不需要的DbContext在所有的（所以你有使用和不使用DB混合行动）
一些逻辑（如条件）不允许访问DbContext（eq ModelState.IsValid）。因此，动作将返回结果BEFORE访问DbContext实例。

所以在这两个（一个也许另一些情况下）DI创建DbContext的范围的情况下，它浪费资源，然后就收集它在请求结束。

我没有做任何性能测试，只是搜索了一些文章的第一。我不认为这将是100％的表现缺乏。我只是想：“嘿人，你为什么创建了对象的实例，如果我根本不使用它的话”。

来源

2017-09-25 Sergey

你有哪个版本的EF？ EF核心具有这种新的功能上下文池。 –

@GertArnold它是核心。我遇到了池注册和迁移组合问题。你的意思是说，dbcontext池的用法摆脱了DbContext实例吗？我认为资源仍然会被浪费（但并不经常是这样）还有更重要的问题即将到来 - dbcontext生存期（缓存，更改跟踪等） – Sergey

在EF6中，上下文创建被明确设计为轻量级操作。所以我不明白为什么在ef-core中引入了上下文池。坦率地说，这让我对ef-core中上下文创建的成本有点怀疑。我只是在文档下面留下了一个关于这个问题的问题。但无论如何，我不会为此担心。设计你的控制器，使它们不包含既需要也不需要上下文的方法。在有切实原因时优化这些内容。 –

为什么你创建对象的实例，如果我根本不使用它的话。

马克塞曼在他的书中Dependency Injection in .NET，说：“创建一个对象实例的东西.Net框架也非常快。任何性能瓶颈您的应用程序可能会出现在其他地方，所以不要担心“。

请注意，的DbContext默认启用延迟加载。只是通过实例化它，对性能没有太大影响。所以，我不会担心Dbcontext。但是，如果您有一些自定义类在构造函数中进行繁重的提升，那么您可能需要考虑重构这些类。

如果你真的想比较性能，你可以用Lazy包装这些依赖关系，看看你获得了多少性能。 Does .net core dependency injection support Lazy。

来源

2017-09-25 18:56:09 Win

可否请您提供声明的证明：“Dbcontext默认启用延迟加载”。或者你的意思是延迟加载导航属性（我作为第一步禁用）？谢谢！我仍然认为DbContext构造函数会进行一些初始化操作，甚至可能会有一些繁重的操作（CodeFirst方法的事件）。它可以预热，更改跟踪器初始化或其他。要查看EF源以便了解DbContext构造函数中发生了什么。如果你有一些关于它的文章 - 我会很感激 – Sergey

你可以注册为懒惰，或者你可以做我所做的，只需注入IMyDbContextFactory，然后你可以调用Create（），当你真正需要它时（它自己的优点/缺点）将返回DbContext。如果构造函数没有做任何事情，它不会是一个巨大的打击，但请记住，它第一次启动时，它会碰到通过并执行所有模型验证的静态构造函数。这个命中只发生一次，但它是一个巨大的打击。

来源

2017-09-26 16:07:07

ASP.NET DbContext实例注入但未使用 - 性能问题与否？

回答

相关问题