使用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/