用于分解具有许多关系的大型 DbContext 的方法

本文关键字:大型 DbContext 方法 关系 许多 分解 用于 | 更新日期: 2023-09-27 18:33:13

我正在做的一个项目有跟踪很多不同实体的DbContext。由于涉及大量关系,因此在生成视图时,第一次从上下文中查询需要很长时间。为了减少启动时间,并更好地将上下文组织到功能区域中,我正在寻找将其拆分的方法。

这些是我到目前为止尝试过的一些方法,以及我看到的问题:

  1. 使用来自大型上下文的 DbSet 子集创建新的较小上下文。

这无济于事,因为 EF 似乎会爬网所有导航属性并包含所有相关实体(至少根据 LINQPad,当上下文在连接面板中展开时,它会显示与上下文相关的所有实体(。我们有一些影响深远的顶级实体,因此很少有子集可以在不删除导航属性和进行大量重构的情况下完全隔离。

  1. 将实体拆分为包含导航属性的类和仅是数据库字段的类,如下所示:
public class PersonLight
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int JobId { get; set; }
}
public class Person : PersonLight
{
    public Job Job { get; set; }
}
public class ContextLight : DbContext
{
    public virtual DbSet<PersonLight> People { get; set; }
}

这里也没有骰子。即使根本不使用 Person,EF(或者再次,可能只是 LINQPad(也包含Person,尽管它不能使用。我认为这是因为 EF 支持继承模式,因此它也结束了对相关实体的爬网。

  1. 执行与 #2 相同的操作,但在不同的项目中使用 PersonLightPerson(或在不同的项目中使用 partial 类(。这是迄今为止最好的选择,但最好PersonFields紧挨着Person以便于参考。

所以我的问题是:

  • 有没有更好的方法来做到这一点,我错过了?
  • 为什么在 #3 中,将它们放在不同的项目中似乎将它们分开,以至于 EF 不会尝试同时包含两者?我尝试将它们放在不同的命名空间中,但这并不能解决问题。

谢谢。

用于分解具有许多关系的大型 DbContext 的方法

加快速度的选项:

  • 生成的视图
  • 界定上下文

具有讽刺意味的是,IIS 应用程序池只需要生成一次视图。基于我的测试的命令行,每次都会生成视图。不知道 linqpad 是做什么的。

顺便说一句,我最初没有添加此链接,因为您将其标记为 EF6。但以防其他人不在 EF6 上。报告了一些性能改进。更多信息在这里:EF6 忍者版