使用Entity Framework Code First时创建外键属性有什么意义？
在查看本网站上的问题和答案并阅读一些关于Code First开发的Google排名前列的教程时，我经常会看到以下模式……
public class Category { public Category() { Products = new Collection(); } public Guid ID { get; set; } public string Name { get; set; } public virtual ICollection 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属性的东西。
所以在我去处理所有外键属性之前，有什么我在这里缺少的吗？ 这样做有什么意义？
谢谢！
是的，我认为不需要外键属性，它们在某种程度上是对象世界中的关系神器。 您可以完全定义关系而无需FK属性。 在Fluent API中，您可以定义关系是可选的还是必需的，并且可以指定数据库表的外键列名称。 这种关系然后被称为独立协会 。
我的理解是外键关联 – 与模型类中公开的外键属性的关系 – 仅存在以使在entity framework中处理关系在某些情况下更容易和更舒适。 例如：
假设您有一个用于创建或编辑产品的Web视图，该视图包含一个combobox，用于选择类别并将其分配给产品。 要在呈现视图时填充combobox，您将加载例如数据库中所有类别的ID和Name 。
页面回发后，您将收到产品的属性和所选类别的ID 。 如果您的产品中没有外键属性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/