友好导航属性的自定义代码生成策略答案

【问题标题】：custom code generation strategy for friendly navigation property友好导航属性的自定义代码生成策略
【发布时间】：2014-07-03 14:18:10
【问题描述】：

我正在使用 EF6 进行 DB-First 生成的 DbContext 和 POCO 对象，并且遇到与许多其他问题相同的问题，即导航属性名称无助于描述与其他表的关系。

例如，如果一个人有一个家庭和工作地址，它将在对象中反映为

public class Person {
    public virtual DbSet<Address> Address; 
    public virtual DbSet<Address> Address1;
}

这个问题在 EF5 上是正确的，但是工具和代码解决方案都不支持 EF6 生成的 t4 模板。 Improve navigation property names when reverse engineering a database

我可以用什么来替换上面的最简单的方法

public class Person {
    public virtual DbSet<Address> Home; 
    public virtual DbSet<Address> Work;
}

并且能够在我需要从头开始时重新生成 edmx 文件（即通过 vs2013 GUI 手动修改 100 个表不是我想要的）。

我浏览了论坛并开始使用调试 T4 模板工具，但希望有比 DIY 更简单的方法。

【问题讨论】：

您是否同时使用：edmx 和 POCO 对象？
是的，据我所知，edmx 是用来创建 poco 对象的，所以我不明白如何才能拥有一个没有另一个？通过 vs 添加“ADO.Net 实体数据模型”并通过 edmx 和 POCO 对象为我创建 DbContext。

【解决方案1】：

如果您不需要 edmx，那么您可以完全删除它，然后使用 EF Power Tools 将您的数据库反转为 Code First。之后使用任何有助于属性重命名的工具，例如Resharper

【讨论】：

此时，我认为从 DB first 迁移到 Code first 超出了范围。理想情况下，我想朝那个方向前进，但现在我更愿意编辑 T4 来为 edmx 生成友好的导航属性。应该不会太难吧？
我无法为此提供足够的代表...没有意识到使用代码优先逆向工程摆脱数据库优先模型是多么容易。谢谢！你让我很快乐！（我花了 1 小时才弄清楚如何将其关闭、切换、测试，现在我可以摆脱所有用于数据注释的元数据文件）
酷！是的，如果您的模型和数据库差别不大，这很容易做到。我对一些导航属性有 1 个小问题，因为由于某种原因它们没有被标记为虚拟，因此延迟加载对它们不起作用。