使用导航属性的时间很明显。但是什么时候应该使用反向导航属性,什么时候不应该使用反向导航属性?
使用导航属性创建双向关系时,是否应该始终使用逆向导航属性?
有指导原则吗?
答案 0 :(得分:1)
它们不影响生成的sql。因此,从数据库结构的角度来看,这并不重要。
但是,当您通过linq从数据库查询数据时,可以在“ where”和“ include”语句中使用该属性。因此,它为您提供了更多创建查询的选项。
我几乎总是特定于反向导航属性。
答案 1 :(得分:1)
我的指导原则是努力使事情变得简单。在我需要之前,我不会使用它们。 :)就像其他任何公共成员或方法(或与此相关的任何代码)一样,只有在存在的理由成立的情况下,它才应该存在。
反属性的存在表明我可以将该实体视为顶级实体,并且需要能够引用其相关实体。例如,一个客户包含订单,那么问题是订单是否应该引用回去它的客户?
如果我可以查询订单(与客户无关),并希望能够在那些查询中访问客户信息,那么拥有逆属性是有益的。
var orderDetails = context.Orders.Where(o => o.OrderDate == DateTime.Today)
.Select(o => new
{
o.OrderId,
o.OrderNumber,
CustomerName = o.Customer.Name
}).ToList();
与在查询中加入客户和订单以通过单向引用访问客户和订单详细信息相反。 (我尝试从内存中编写一个示例,但是它太丑陋太快了。:D)
没有意义的是“始终”具有双向引用。例如,当您拥有诸如Address和AddressType之类的东西时。 AddressType永远不需要知道该类型的地址列表,即使您确实想查询该详细信息,也很容易通过单向引用进行过滤。将“地址”(相对于地址类型)作为顶级引用是有意义的,因为您可能要引用来自客户的订单或来自订单的客户。