实体框架导航属性生成规则

Question

我想了解Entity Framework在命名/生成导航属性方面遵循哪些规则。我观察到了几种看起来不合理的情况，所以想知道有没有人确切地知道它们是如何工作的。

场景1：

public class Post
{
    public int Id { get; set; }
    public User Author { get; set; }
} 

   生成

默认情况下，导航属性生成名为[PropertyName]_Id的外键。

场景2：

如果手动指定FK Id，则EF生成格式为[PropertyName]_Id的属性是有道理的，它将遵循相同的规则，但需要注意：

public class Post
{
    public int Id { get; set; }
    public int? Author_Id { get; set; }
    public User Author { get; set; }
}

   生成

正如您所看到的，它不会自动注册为导航属性。

情况3：

如果对于情况2不起作用，为什么它可以适用于其他命名约定？

public class Post
{
    public int Id { get; set; }
    public int? AuthorId { get; set; }
    public User Author { get; set; }
}

   生成

导航属性检测和生成的规则是什么？

- undefined

---

我想把你关于导航属性的好博客文章链接回来。 - orad

@orad 哈哈，很酷，我实际上是作为那篇文章的研究之一而提出这个问题的 :) - undefined

Answer 1

这是预期的行为，基于EF采用的两种不同约定。

• 在第一个示例中，您使用独立关联，其中您的实体没有FK属性。 EF将在数据库中创建使用简单模式的FK：NameOfNavigationProperty_NameOfRelatedPK。该约定遵循传统数据库命名。
• 在第二个示例中，您定义了与EF使用的FK相同名称的属性。 EF检测到此并将其生成的FK加1。为什么您的属性未用作FK的原因是第二个约定搜索FK属性。该约定希望FK属性将具有此名称（约定遵循传统的.NET命名）：
  • NameOfNavigationPropertyNameOfRelatedPK由 NavigationPropertyNameForeignKeyDiscoveryConvention 提供
  • NameOfRelatedTypeNameOfItsPK由 TypeNameForeignKeyDiscoveryConvention 提供
  • NameOfRelatedPK由 PrimaryKeyNameForeignKeyDiscoveryConvention 提供
• 在最后一个示例中，您正确定义了FK属性，EF检测到它，因此使用外键关联。

- Ladislav Mrnka

---

这里有一些关于关系和约定的文档。链接 - Yoshihiro Tanaka

Answer 2

除了@Ladislav Mrnka上面的答案，您还可以在这里找到实体框架默认约定的详细参考： http://msdn.microsoft.com/en-us/library/system.data.entity.modelconfiguration.conventions(v=vs.103).aspx

- user3083619