太多的导航性能可太多

如果我有一个实体：太多的导航性能可太多

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对象的最佳做法或它并不总是必需的（通常有一些经验法则）？

有时我觉得我正在创建太大的对象，我想知道这是否会对性能产生影响？

来源

2014-06-29 1110

角色ID应在用户表中，此用户具有此角色 –

完全依赖于您正在建模的数据 – joelmdev

您认为将100个相关表格拖放到您的dbcontext可能不是最高性能的解决方案，并且ef将拖动所有可以看作dbset，导航属性或流畅配置的表格。

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

然后，您需要另一个dbcontext用于其他感兴趣的领域：该概念被称为有界上下文。（Ref Julie Lerman，Eric Evans DDD）然后，您需要在应用中做更多的工作来支持同一应用中的多个数据库上下文，但可以完成 - （请参阅企业级别的Julie Lerman）但是，如果您只需要一个dbcontext你的应用程序在你的模型的范围被限制在一个表的子集，然后这将工作。

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

来源

2014-06-29 14:40:37 Hargrovm

太多的导航性能可太多

回答

相关问题