使用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#对象上拥有外键属性有什么意义呢？在上面的例子中,你可以省略CategoryID从Product阶级,一切都将工作得很好.外键Category_ID仍将在数据库中创建.

我唯一能想到的是,人们可能希望能够使用可空类型而不是流畅的API来指定关系是否是可选的,但我认为它确实混淆了具有a 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/