如何防止实体框架代码中的相关实体的循环加载

Mat*_*son 7 entity-framework

我是Entity Framework的新手,我正在尝试学习如何使用Code First从数据库加载实体.

我的模型包含一个用户:

public class User
{
    public int UserID { get; set; }

    [Required]
    public string Name { get; set; }

    // Navigation Properties
    public virtual ICollection<AuditEntry> AuditEntries { get; set; }
}
Run Code Online (Sandbox Code Playgroud)

每个用户都可以拥有一组审计条目,每个条目都包含一条简单的消息:

public class AuditEntry
{
    public int AuditEntryID { get; set; }

    [Required]
    public string Message { get; set; }

    // Navigation Properties
    public int UserID { get; set; }
    public virtual User User { get; set; }
}
Run Code Online (Sandbox Code Playgroud)

我有一个DBContext,它只暴露了两个表:

public DbSet<User> Users { get; set; }
public DbSet<AuditEntry> AuditEntries { get; set; }
Run Code Online (Sandbox Code Playgroud)

我想要做的是加载包含消息的AuditEntry对象列表以及包含UserID和Name属性的相关User对象.

List<AuditEntry> auditEntries = db.AuditEntries.ToList();
Run Code Online (Sandbox Code Playgroud)

因为我将导航属性标记为虚拟并且我没有禁用延迟加载,所以我获得了一个无限深的对象图(每个AuditEntry都有一个User对象,其中包含AuditEntries列表,每个AuditEntries都包含一个User对象,包含AuditEntries列表等)

如果我想要序列化对象(例如在Web API中作为结果发送),这是不好的.

我已经尝试关闭延迟加载(通过从模型中的导航属性中删除虚拟关键字,或者将此.Configuration.LazyLoadingEnabled = false;添加到我的DBContext).正如预期的那样,这会导致AuditEntry对象的平面列表,其中User设置为null.

随着延迟加载,我试图像这样急切加载用户:

var auditentries = db.AuditEntries.Include(a => a.User);
Run Code Online (Sandbox Code Playgroud)

但这导致与之前相同的深度/循环结果.

如何加载一个级别(例如包括用户的ID和名称)而不将后向引用/后续导航属性加载回原始对象并创建循环?

Mat*_*son 5

经过多次黑客攻击后,我在 Linq 查询中使用动态返回类型和投影提出了以下潜在的解决方案:

public dynamic GetAuditEntries()
{
    var result = from a in db.AuditEntries
                 select new
                 {
                     a.AuditEntryID,
                     a.Message,
                     User = new
                     {
                         a.User.UserID,
                         a.User.Username
                     }
                 };

    return result;
}
Run Code Online (Sandbox Code Playgroud)

这会(在内部)生成以下看起来合理的 SQL:

SELECT 
[Extent1].[AuditEntryID] AS [AuditEntryID], 
[Extent1].[Message] AS [Message], 
[Extent1].[UserID] AS [UserID], 
[Extent2].[Username] AS [Username]
FROM  [dbo].[AuditEntries] AS [Extent1]
INNER JOIN [dbo].[Users] AS [Extent2] ON [Extent1].[UserID] = [Extent2].[UserID]
Run Code Online (Sandbox Code Playgroud)

这产生了我想要的结果,但似乎有点啰嗦(特别是对于比我的示例复杂得多的现实生活模型),并且我质疑这会对性能产生影响。

优点

  • 这为我返回对象的确切内容提供了很大的灵活性。由于我通常在客户端进行大部分 UI 交互/模板,因此我经常发现自己必须创建模型对象的多个版本。我通常需要一定的粒度,让用户可以查看哪些属性(例如,我可能不想在 AJAX 请求中将每个用户的电子邮件地址发送到低权限用户的浏览器)

  • 它允许实体框架智能地构建查询并仅选择我选择投影的字段。例如,在每个顶级 AuditEntry 对象中,我希望看到 User.UserID 和 User.Username,但不是 User.AuditEntries。

缺点

  • 我的 Web API 返回的类型不再是强类型的,因此我无法基于此 API 创建强类型的 MVC 视图。碰巧这对于我的具体情况来说不是问题。

  • 以这种方式从大型/复杂模型手动投影可能会产生大量代码,看起来工作量很大,并且有可能在 API 中引入错误。这必须仔细测试。

  • API 方法与模型的结构紧密耦合,并且由于这不再基于我的 POCO 类完全自动化,因此对模型所做的任何更改都必须反映在加载它们的代码中。

包括方法?

我对 .Include() 方法的使用仍然有点困惑。据我所知,此方法将指定相关实体应与指定实体一起“急切加载”。但是,由于指导似乎是导航属性应放置在关系的两侧并标记为虚拟,因此 Include 方法似乎会导致创建一个循环,这对其有用性产生重大负面影响(尤其是在序列化时) 。

就我而言,“树”看起来有点像:

AuditEntry
    User
        AuditEntries * n
            User * n
                etc
Run Code Online (Sandbox Code Playgroud)

我非常有兴趣听到有关此方法的任何评论、以这种方式使用动态的影响或任何其他见解。