太多的导航属性会不会太多?

本文关键字：太多 会不会 导航 属性 | 更新日期: 2023-09-27 18:10:46

如果我有一个实体:

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

和另一个实体:

public class Role
{
   public int RoleId{get;set}
}

我想通过EF代码首先建模关系，所以我添加了:

User.cs 

public virtual ICollection<Role> Roles {get;set;}

Role.cs 

public virtual User User {get;set;}

这允许我获得这样的用户角色:

context.Users.Roles.ToList();

而User是数据库中的主要对象。它可以有100个表的关系。

添加ICollection<T>和User对象是最佳实践还是并不总是需要(通常有一些经验法则)?

有时我感觉我创建了太大的对象，我想知道这是否会对性能产生影响?

太多的导航属性会不会太多?

您认为将100个相关表拖拽到dbcontext中可能不是最有效的解决方案，ef将拖拽它可以视为dbset、导航属性或流畅配置的所有表，这是正确的。

然而，如果你需要在dbcontext中从角色导航到用户，而用户实体的导航属性指向100个表，那么你的解决方案将是在这个特定的dbcontext中告诉ef忽略你不关心的表，比如modelbuilder.ignore('orders')，假设你可以从用户以某种方式导航到订单。通过这种方式，你可以对图进行修剪，只考虑你需要的实体。

然后，您需要另一个dbcontext用于其他感兴趣的领域:这个概念称为有界上下文。(参考Julie Lerman, Eric Evans DDD)然后你需要在你的应用程序中做更多的工作来支持同一应用程序中的多个db上下文，但它可以做到-(参见Julie Lerman on enterprise ef)但是，如果你只想在你的应用程序中使用一个dbcontext，其中你的模型的范围仅限于表的子集，那么这将起作用。

我认为你可以使用ef工具来查看dbcontext模型中表的只读关系图。然后，您可以确认您的修剪进行得如何。

相关文章：