为每个页面使用不同的DbContext类的好习惯吗？

Question

我正在优化和重构大型ERP类型的ASP.NET应用程序，以实现更快的开发体验。 我们目前有一个大型模型（600多个表/实体），它在应用程序启动时创建，大约需要15秒。 （此时，我们正在使用NHibernate和代码优先映射）

我正在尝试在编译完成后实现页面的最快渲染。

我想知道每页是否有一个DbContext是一个好习惯，它只包含使用此页面所需的实体/映射。 每个页面都被视为一个独特的元素，可以自己携带。

编辑：我不是在谈论重用DbContext的实例，而是使用不同的DbSet的不同对象。将为每个请求创建一个不同的实例。

Answer 1

  

我想知道一个DbContext是否是一个好习惯   每页只包含所需的实体/映射   使用此页面。

我认为每页都有一个专用的DbContext类型是个好主意。

• 每个DbContext的类型模型将在整个应用程序域生命周期内保留内存占用量。我会说大约20种实体类型的足迹将是5MB。
• 您将很难定义每个DbContext类型的边界（根据具体情况忽略实体的导航属性将迫使您定义许多专用的映射配置）。这不是一个坏主意，但我想Linq的支持几乎是无用的，我认为微观风格更适合这种方法。

您也可以选择有界的上下文：将您的域模型分成对应于相同关注点的实体集（假设每个关注点最多50个实体）并且每个关注点使用专用的DbContext类型（没有导航属性）跨越不同DbContexts的实体）。请注意，您可以定义非常简单的交叉关注（主要是只读）映射，以在整个应用程序中使用交叉关注概念（例如，公开UserSummary实体的主要属性的User实体）

关于加速启动，我想这可以帮助3 STEPS FOR FAST ENTITYFRAMEWORK 6.1 CODE-FIRST STARTUP PERFORMANCE

Answer 2

每个请求使用DbContext是一种很好的做法。

如果您在View上呈现部分页面，那么如果您仍然使用相同的上下文则会更好。

一般情况下，您的上下文会在请求结束时自动处理（例如，如果您在应用程序启动时创建上下文有一些例外，但不管怎么说都不应该这样做），但最好在最后手动处理它请求。

但是，如果你谈论最佳性能，我会在会议上，StackOverflow团队讨论SO如何工作（它也写在MVC上）。

他们说他们根本不使用 EF 或任何其他 ORM 因为它会创建大量中间对象而GarbageCollector无法处置它快速的。所以他们写的都是旧的简单 ADO.NET

Answer 3

到目前为止，这正是我一直在使用的模型，一切都很顺利。 DbContext应该尽可能少地存在，并且应该表示您正在操作的相关操作的数据库上下文（得到它？）。它与为ASP.NET MVC中的每个请求创建一个新的控制器实例几乎相同。

第一个实例创建后，后续的实例非常快。

事实上，尝试使用DbContext比自然（缓存它可能）更多，会让你遇到麻烦。这是因为它的状态跟踪往往像迷人的王子一样成长。此外，通过在旧的上下文中附加实体来进行直接更新或删除，其中之前已经加载了具有该主键的实体（可能在某些不相关的操作中）将引发异常。

底线：它没有被称为DbCONTEXT。不久使用它然后处理它。

编辑：本文仅涉及实体框架。我不熟悉NHibernate。

Answer 4

实体框架6增加了对在单个数据库中使用多个模型的支持，包括迁移。但是每个模型都需要独立于其他模型，即没有共享表和实体。可以完成共享实体，但迁移变得更加复杂。

此博客文章Data Points - EF6 Code First Migrations for Multiple Models详细介绍了EF6支持的内容，并且还提供了有关跨模型共享实体的其他演示文稿的链接。

如果您主要关注开发过程中花费的时间，那么您可以为没有启用任何迁移的每个页面或一组页面制作单独的DbContexts（因此不应该有任何问题）与DbContexts之间的共享实体）。然后，您有一个DbContext，您在生产中使用它包含所有实体并具有迁移。为它们提供所有接口并通过依赖注入将它们绑定在一起，然后您可以在DbContexts之间轻松切换以进行开发，测试和生产。