實體框架（4.1）中具有一對多雙向關係有哪些優點和缺點？

我正在開發一個利用實體框架的新項目。我愛上了關係反向，兩種類型的導航屬性都會讓我的生活變得更加輕鬆。問題是：我們的項目經理認爲使用此設施可能會導致錯誤，因此建議我們不要使用它。實體框架（4.1）中具有一對多雙向關係有哪些優點和缺點？

比方說，我們有類別和產品：

public class Product 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
    public virtual Category Category { get; set; } 
} 

public class Category 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
    public virtual ICollection<Product> Products { get; set; } 
}

他說，一個也可以，錯誤，productZ.Category設置爲categoryX，然後做一個categoryY.Products.Add（productZ）爲例。那麼當我們保存上下文時，什麼樣的關係會持續存在？最後一個？好的，如果第一個是正確的類別呢？而這種錯誤很難調試（我同意這一點）。

我不認爲這種情況會發生，但我真的尊重他的意見，他比我更有經驗，但我真的想說服他讓我們具有雙向導航屬性，唯一的理由是：if每個人都在這樣做，那麼它不能這麼糟糕。 :)

你們可以幫我一些更堅實的論點？

來源

2011-10-05 Henrique Miranda

人們可以通過錯誤...

人們也可以編寫單元測試，以驗證代碼集預期的關係。您始終可以犯錯誤並刪除導航屬性不是避免此問題的解決方案。解決方案是驗證您的代碼是否符合預期=測試和代碼覆蓋率。

你問的是更多關於設計你的課程 - 而不是關於錯誤。雙方都有導航屬性有意義嗎？您是將產品添加到產品類別還是將產品分類？你需要提供兩種方式嗎？產品能否存在沒有類別？您是分開處理產品和類別還是聚合？基於對這些問題的回答，您有時可能會發現關係一側的導航屬性不是必需的。

來源

2011-10-05 14:48:13

當我們添加一個新產品時，我們主要將這個類別分配給產品，然後插入它。有時我們會使用產品及其類別，但也需要從一個類別（甚至是所有類別）訪問所有產品。看到我的觀點？ –

單個類別或所有類別的產品都可以通過對產品進行單獨查詢來訪問。 –

我會同意你的項目經理，特別是在閱讀「他比我更有經驗」時，因爲它表明至少有些團隊有點綠色（你自己？），並且可能會犯這種錯誤提及。您所描述的問題很像將值存儲在多個數據庫中（有時是必需的惡意），而不是將其中一個數據庫設置爲主數據庫。

雖然雙向「關係」可能會讓事情變得更容易一些，但是通過簡單的編碼錯誤就會增加混淆數據的風險，這並不那麼容易。你可以在不添加雙向支持的情況下導航（可能不是簡單的聲明，但可以完成），但我必須有強烈的使用它們的論據。

來源

2011-10-05 14:46:36

那麼，缺乏經驗並不像缺乏經驗一樣。這就是說，是的，我擔心他對球隊沒有足夠的信心讓這個潛在的麻煩製造者打開。 –

我並不是說沒有經驗，所以我希望它沒有遇到這種情況。但把這樣的方法交給一個經驗較少的團隊就好像給一個年齡較大的孩子遞槍。很可能，沒有什麼不好的事情會發生，但潛力更大。使用可以完全封裝的代碼，您可以降低風險，但是當您談論自己的域模型時，無法完全封裝以保護開發人員不受自己的影響。除非有人能說服我爲什麼需要，否則我會發現風險太大。 –

我的想法是「如果這是非常危險的，那麼爲什麼在全世界每一個EF範例都實現了它，並且它們都沒有警告這類問題？」。我認爲應該真的有人爲了犯這種錯誤。 –

實體框架（4.1）中具有一對多雙向關係有哪些優點和缺點？

回答

相關問題