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

Question

在查看此站点上的问题和答案以及阅读一些 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 中，您可以定义关系是可选的还是必需的，并且可以指定数据库表的外键列名称。这种关系称为独立关联。

我的理解是，外键关联 - 与模型类中公开的外键属性的关系 - 存在的目的只是为了在某些情况下更轻松、更舒适地处理 Entity Framework 中的关系。例如:

假设您有一个用于创建或编辑产品的 Web View ，并且该 View 包含一个用于选择类别并将其分配给产品的组合框。要在呈现 View 时填充组合框，您需要从数据库中加载所有类别的 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/