使用Entity Framework Code First時創建外鍵屬性有什么意義？

Question

在查看本網站上的問題和答案並閱讀一些關於Code First開發的Google排名前列的教程時，我經常會看到以下模式......

public class Category
{
    public Category()
    {
        Products = new Collection<Product>();
    }
    public Guid ID { get; set; }
    public string Name { get; set; }
    public virtual ICollection<Product> Products { get; set; }
}

public class Product
{
    public Guid ID { get; set; }
    public string Name { get; set; }
    public DateTime DateAdded { get; set; }
    public Guid CategoryID { get; set; } // Seemingly redundant property
    public virtual Category Category { get; set; }
}

在搜索Code First教程時，會出現以下兩個使用相同模式的頁面：

http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx

http://www.codeproject.com/Articles/327945/Architecture-Guide-ASP-NET-MVC3-Entity-Framework-C

問題：那么在Code First C＃對象上擁有外鍵屬性有什么意義呢？ 在上面的示例中，您可以省略Product類中的CategoryID ，一切都可以正常工作。 仍將在數據庫中創建外鍵Category_ID 。

我唯一能想到的是人們可能希望能夠使用可空類型而不是流暢的API來指定關系是否是可選的，但我認為它確實混淆了具有Category和CategoryID屬性的東西。

所以在我去除所有外鍵屬性之前，有什么我在這里缺少的嗎？ 這樣做有什么意義？

謝謝！

Answer 1

是的，我認為不需要外鍵屬性，它們在某種程度上是對象世界中的關系神器。 您可以完全定義關系而無需FK屬性。 在Fluent API中，您可以定義關系是可選的還是必需的，並且可以指定數據庫表的外鍵列名。 這種關系然后被稱為獨立協會 。

我的理解是， 外鍵關聯 - 與模型類中公開的外鍵屬性的關系 - 僅存在於使實體框架中的關系在某些情況下更容易和更舒適。 例如：

假設您有一個用於創建或編輯產品的Web視圖，該視圖包含一個組合框，用於選擇類別並將其分配給產品。 要在呈現視圖時填充組合框，您將加載例如數據庫中所有類別的ID和Name 。

頁面回發后，您將收到產品的屬性和所選類別的ID 。 如果你沒有一個外鍵屬性CategoryID在你的Product ，你就必須建立的關系是這樣的：

var category = new Category { ID = IDFromComboBox };
context.Categories.Attach(category);
product.Category = category;

使用FK屬性，您只需要一行：

product.CategoryID = IDFromComboBox;

實體框架版本1（.NET 3.5）中不存在外鍵屬性，並且已在EF版本4（.NET 4）中引入，以更好地支持上述方案。

可以找到關於外鍵關聯的批判性觀點，在Ladislav的博客中非常好地討論了這兩種類型的關聯之間的區別：

http://www.ladislavmrnka.com/2011/05/foreign-key-vs-independent-associations-in-ef-4/