在实体implemening导航属性框架

的另一种方法

来定义复杂的实体导航属性官方的做法是：在实体implemening导航属性框架

public class SuperEntity 
{  
    public int Id { get; set; } 
    //Other properties 
} 

public class LowerEntity 
{ 
    public int Id { get; set; } 
    public int SuperEntityId { get; set; } 
    public virtual SuperEntity SuperEntity { get; set; }  
    //Other properties 
}

这里最主要的是一个类，引用（允许导航链接超级实体）有public SuperEntity SuperEntity { get; set; }财产，以及它在public int SuperEntityId { get; set; } Id。

我已经走了几天进入我的实体设计，在“较低的实体”中省略了public int SuperEntityId { get; set; }属性。所以我只能通过虚拟SuperEntity属性进行导航。一切正常！但是我有人告诉我，它在数据库中创建了过多的表格。我检查过了，这不是事实。当我使用我的方法时，数据库表具有SuperEntityId列，并自动使用所引用的实体标识填充它。那么public int SuperEntityId { get; set; }这个字段有什么意义呢？或者，也许，我正在做的事情成为EF的4.3版本的“新鲜”版本？

来源

2012-08-13 Maxim V. Pavlov

SuperEntityId的意义在于，它有时更容易在应用程序中使用外键属性，而您的上下文在整个时间内并未处于活动状态，例如，一个web应用程序。在这种情况下，使用外键属性比试图将对象B附加到对象A要容易得多。
据我所知，在导航属性中，EF使用一个对象来跟踪2个对象。所以如果你想把对象B和对象A结合起来，在一个断开连接的应用程序中，仅仅在对象A上设置属性是不够的，你还必须在变更跟踪器中摆弄对象A的条目来注册B和A. 设置一个外键属性就等于这个摆弄。当我们刚刚开始使用EF并且不知道所有这些时，每次我们想要连接2个对象时，例如B到A，并且B已经存在于DB中，上下文认为B是新对象而不是现有对象，并且将该记录复制到DB中。

来源

2012-08-13 10:54:15

也许你是对的，我可能会在后面扼杀这个问题。谢谢。 – 2012-08-13 10:58:30

如果您的对象在相同的上下文实例中浮动，并且永远不需要显式附加（通常不需要在桌面应用程序中），那么您很可能不会遇到太多问题。 – 2012-08-13 11:02:19

就在今天，我注意到在我的测试数据库中，我有一些重复的记录。它们是完全重复的，包括在多对多桥表中定义的关系。我感到困惑，但只是删除他们认为这可能是新的本地数据库的问题。你所描述的更合理，我正在考虑将导航属性全部放在一起。 – 2012-10-01 03:31:07

它不会创建过多的表，但它可能会在该数据库上生成额外的或更长的查询。但这取决于你如何使用这些实体。

来源

2012-08-13 10:34:17 podiluska

在实体implemening导航属性框架

回答

相关问题