使用 Entity Framework Code First 时创建外键属性有什么意义？

Question

在查看此站点上的问题和答案并阅读一些 Google 排名最高的 Code First 开发教程时，我经常看到以下模式...

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 和 @ 确实会混淆事物987654329@财产。

所以在我四处走动并删除所有外键属性之前，这里有什么我遗漏的吗？这样做有什么意义？

谢谢！

Answer 1

是的，我认为不需要外键属性，它们在某种程度上是对象世界中的关系工件。您可以在没有 FK 属性的情况下完全定义关系。在 Fluent API 中，您可以定义关系是可选的还是必需的，并且您可以指定数据库表的外键列名。这种关系称为独立关联。

我的理解是，外键关联 - 与模型类中公开的外键属性的关系 - 仅存在于使实体框架中的关系在某些情况下更容易和更舒适。例如：

假设您有一个用于创建或编辑产品的 Web 视图，并且该视图包含一个用于选择类别并将其分配给产品的组合框。要在呈现视图时填充组合框，您将加载例如数据库中所有类别的 ID 和 Name。

回发页面后，您将收到产品的属性和所选类别的ID。如果您的 Product 中没有外键属性 CategoryID，则必须以这种方式创建关系：

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

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

product.CategoryID = IDFromComboBox;

Entity Framework 版本 1 (.NET 3.5) 中不存在外键属性，并且已在 EF 版本 4 (.NET 4) 中引入以更好地支持上述场景。

可以找到关于外键关联的批判性观点，并且在 Ladislav 的博客中很好地讨论了两种关联之间的区别：

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