实体有其他实体的许多藏品EF 4.2

我需要在我的域名大量表的模型...我试图找出如何正确规范如下：实体有其他实体的许多藏品EF 4.2

我已地址实体是摘要

的StreetAddress和POBoxAddress从地址导出在这一领域

许多其他实体都需要地址，例如集合：

Vendor.Addresses 
CondoComplex.Addresses 
Employee.Addresses 
PositionShift.Addresses 
Location.Addresses 
Guest.Addresses 
Property.Addresses 
Owner.Addresses

等...许多其他的实体...所以我很困惑如何在EF中存储这些关联？作为带有鉴别器列的多对多tph，或者我只是错过了树木的森林，还有一个不那么复杂的解决方案？

来源

2011-11-29 Greg Foote

继承在实体映射中被滥用（实际上，它通常被过度使用，但特别是在映射对象的情况下，which aren't really strongly OO in the first place并且通常不应该具有行为）。大多数时候，你应该避免它，因为它使查询和数据结构变得更加复杂。真的需要StreetAddress和POBoxAddress两种不同的类型吗？为什么？邮局不会在意。

在将复杂性带入模型之前，需要有一个清晰，引人注目的继承案例。在这种情况下，你不仅没有它，而且你的问题表明你在这里完全没有使用继承。

来源

2011-11-29 19:51:27

我在想，邮政信箱和街道地址实体的传承正在采取的东西有点太远了...但是我刚刚完成了关于域建模和常规表单的一本书......即使我删除继承并将这些属性添加回地址实体，我仍然对EF如何设置关系感到朦胧...它会将10 FK添加到我的地址实体吗？或者它会创建10个不同的表来保存这些信息？ –

如果您要创建具有所有您需要的属性（城市，街道，邮政编码等）的地址类，并且您将在其他类中引用它，则外键将分配给相应的表。 – torm

@GregFoote那么，您可以按照您喜欢的方式设计数据库，并构建相应的EF模型（即使使用Code First）。 10个可空的FK肯定是一种选择。另一个是多对多的映射表（例如'VendorAddresses'等） –

如果不考虑地址实体的复杂性，如果相关实体不会共享地址我认为创建多对多关系并不重要。我不知道你的抽象Address类的样子，但我会去简单地用

public List<Address> Addresses {get;set;}

在实体

来源

2011-11-29 19:53:52 torm

所以我应该为每个希望拥有地址集合的其他实体添加一个外键？ –

或创建所有其他人都会继承的父类 – torm

实体有其他实体的许多藏品EF 4.2

回答

相关问题