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

Question

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

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

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

编辑:我不是在谈论重用DbContext的实例,而是使用不同的DbSets的不同对象.将为每个请求创建不同的实例.

Answer 1

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

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

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

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

至于加速启动,我想这可以帮助快速实施框架的第3步6.1代码 - 第一次启动性能

Answer 2

DbContext根据每个请求使用它是一个很好的做法。

如果您在视图上渲染部分页面，那么最好仍然使用相同的上下文。

一般来说，您的上下文会在请求结束时自动处理（当然，如果您在应用程序启动时创建上下文，则有一些例外，但无论如何您都不应该这样做），但最好在请求结束时手动处理它。

但如果你谈论最佳性能，我在会议上 StackOverflow 团队讨论了 SO 的工作原理（它也是基于 MVC 编写的）。

他们说他们根本不使用EF或任何其他ORM，因为它会创建大量中间对象并且GarbageCollector无法足够快地处理它。所以他们把所有内容都写在古老的普通ADO.NET上