地圖很多：從多個實體類型可選的關係EF CodeFirst

我們有3個實體之間的相互關係爲這樣：地圖很多：從多個實體類型可選的關係EF CodeFirst

美孚有許多附件
酒吧有許多附件
每個附件可以屬於到Foo或Bar。

什麼是使用DbModelBuilder進行建模的最佳方法？

如果我們嘗試：

modelBuilder.Entity<Foo>().HasMany(t => t.Attachments).WithOptional() 
    .Map(m => m.MapKey("FOO_ID")).WillCascadeOnDelete(true); 
modelBuilder.Entity<Bar>().HasMany(t => t.Attachments).WithOptional() 
    .Map(m => m.MapKey("BAR_ID")).WillCascadeOnDelete(true);

這不是一個非常乾淨的數據模型： *的附件表將有兩個FK列，每一個可能的父實體（「FOO_ID」，「BAR_ID」）。如果我們增加需要附件的實體的數量，它會膨脹表格。 *我們需要使反向引用可選，儘管當然附件總是附加到實體上。它不一定是一個Foo，也不一定是一個Bar。但是架構允許所有FK設置爲NULL的附件，儘管它在業務視圖中無效。 *在理論上，一個附件可能與Foo和Bar都有關聯，這是無效的。

相反，我們可能會映射到結表「T_FOO_ATTACHMENT」和「T_BAR_ATTACHMENT」的關係： * T_FOO_ATTACHMENT有需要外鍵美孚（FOO_ID）和必需的FK到附件（ATTACHMENT_ID）。 * T_BAR_ATTACHMENT同樣適用

缺點： *附件仍然可以鏈接到Foo和酒吧。 *附件甚至可以鏈接到多個Foo，這也是無效的。理想情況下，我們可以使用流暢的語法來添加阻止這種情況的數據庫約束。

來源

2012-06-04 chiccodoro

這不是一個非常乾淨的數據模型：本附件表將有 2 FK列，每一個可能的父實體（「FOO_ID」，「BAR_ID」）。

但是從關係角度來看它是絕對正確的 - 如果你想和另一個表有關係，你需要一個新的外鍵。

但所有FK的設置爲null的附件將被模式被允許雖然它不是從業務視圖有效。理論上一個附件可以鏈接到Foo和Bar，這不是有效。

這是您的業務邏輯。使用您當前的模型，您必須在您的應用程序中執行它。

你在找什麼是某種命名的關係，其中Attachment不僅有FK，而且還有相關表的名稱。這是你在關係層面上無法實現的 - 它是數據級別（再次是業務邏輯），它不能與EF映射。

來源

2012-06-04 14:18:08

謝謝拉迪斯拉夫。如果你的名字出現在答案中，總會有很好的希望:-) - 對於指定的關係：我也會遠離這些。我的面向對象的思想告訴我要避免循環引用，因此我試圖在附件中根本沒有任何FK，只是用結點表來代替。但那可能是過度工程。 – chiccodoro

...是的，實際上業務邏輯已經被代碼覆蓋了。用戶添加附件的唯一方式將始終與業務規則保持一致。 – chiccodoro

地圖很多：從多個實體類型可選的關係EF CodeFirst

回答

相關問題