导航属性太多可能太多了

时间:2014-06-29 14:21:40

标签: c# entity-framework entity-framework-6

如果我有实体:

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

另一个实体:

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

我想通过EF Code First模拟关系船,所以我补充说:

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对象是最佳做法还是并非总是需要(通常会有一些经验法则)?

有时候我觉得我创造的对象太大了,我想知道这会对性能有什么影响吗?

1 个答案:

答案 0 :(得分:0)

您认为将100个相关表拖到dbcontext可能不是最高性能的解决方案是正确的,并且ef将拖入所有可以看作dbset,navigation属性或fluent配置的表。

但是,如果您需要在dbcontext中从角色导航到用户,并且用户实体具有指向100个表的导航属性,那么您的解决方案将在此特定dbcontext中告诉ef忽略您不关心的表使用类似于modelbuilder.ignore('orders')的东西,假设用户可以通过某种方式导航到订单。通过这种方式,您可以修剪图形,只考虑您需要的实体。

然后,您需要为其他感兴趣的领域提供另一个dbcontext:该概念称为有界上下文。 (参考Julie Lerman,Eric Evans DDD)然后你需要在你的应用程序中做更多的工作来支持同一个应用程序中的多个数据库上下文,但它可以完成 - (请参阅企业ef上的Julie Lerman)但是如果你只想要一个dbcontext您的应用程序,其中模型的范围仅限于表的子集,然后这将有效。

我认为您可以使用ef power tools查看dbcontext模型中表的只读图。然后,您可以确认修剪的进展情况。

相关问题