在實體implemening導航屬性框架

的另一種方法

來定義複雜的實體導航屬性官方的做法是：在實體implemening導航屬性框架

public class SuperEntity 
{  
    public int Id { get; set; } 
    //Other properties 
} 

public class LowerEntity 
{ 
    public int Id { get; set; } 
    public int SuperEntityId { get; set; } 
    public virtual SuperEntity SuperEntity { get; set; }  
    //Other properties 
}

這裏最主要的是一個類，引用（允許導航鏈接超級實體）有public SuperEntity SuperEntity { get; set; }財產，以及它在public int SuperEntityId { get; set; } Id。

我已經走了幾天進入我的實體設計，在「較低的實體」中省略了public int SuperEntityId { get; set; }屬性。所以我只能通過虛擬SuperEntity屬性進行導航。一切正常！但是我有人告訴我，它在數據庫中創建了過多的表格。我檢查過了，這不是事實。當我使用我的方法時，數據庫表具有SuperEntityId列，並自動使用所引用的實體標識填充它。那麼public int SuperEntityId { get; set; }這個字段有什麼意義呢？或者，也許，我正在做的事情成爲EF的4.3版本的「新鮮」版本？

來源

2012-08-13 Maxim V. Pavlov

SuperEntityId的意義在於，它有時更容易在應用程序中使用外鍵屬性，而您的上下文在整個時間內並未處於活動狀態，例如，一個web應用程序。在這種情況下，使用外鍵屬性比試圖將對象B附加到對象A要容易得多。
據我所知，在導航屬性中，EF使用一個對象來跟蹤2個對象。所以如果你想把對象B和對象A結合起來，在一個斷開連接的應用程序中，僅僅在對象A上設置屬性是不夠的，你還必須在變更跟蹤器中擺弄對象A的條目來註冊B和A. 設置一個外鍵屬性就等於這個擺弄。當我們剛剛開始使用EF並且不知道所有這些時，每次我們想要連接2個對象時，例如B到A，並且B已經存在於DB中，上下文認爲B是新對象而不是現有對象，並且將該記錄複製到DB中。

來源

2012-08-13 10:54:15

也許你是對的，我可能會在後面扼殺這個問題。謝謝。 – 2012-08-13 10:58:30

如果您的對象在相同的上下文實例中浮動，並且永遠不需要顯式附加（通常不需要在桌面應用程序中），那麼您很可能不會遇到太多問題。 – 2012-08-13 11:02:19

就在今天，我注意到在我的測試數據庫中，我有一些重複的記錄。它們是完全重複的，包括在多對多橋表中定義的關係。我感到困惑，但只是刪除他們認爲這可能是新的本地數據庫的問題。你所描述的更合理，我正在考慮將導航屬性全部放在一起。 – 2012-10-01 03:31:07

它不會創建過多的表，但它可能會在該數據庫上生成額外的或更長的查詢。但這取決於你如何使用這些實體。

來源

2012-08-13 10:34:17 podiluska

在實體implemening導航屬性框架

回答

相關問題