實體有其他實體的許多藏品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

回答

相關問題