如何从现有数据库生成POCO代理
我最近切换到实体框架5.现在，我想从现有的数据库生成POCO类，也需要延迟加载和更改跟踪。 所以所有的标量属性都应该是虚拟的以及导航属性。
添加新的ADO.Net实体数据模型以.edmx文件和其他一些.cs和.tt文件结尾。
首先，我想知道为什么默认生成的POCO类不符合变更跟踪代理的要求，即标量属性不是虚拟的。
其次，我怎样才能生成启用代理的poco类？
PS：我接受Slauma的答案是迄今为止最好的和唯一的答案，但我不同意它的第一部分。 这是我的观点
Slauma谈到代理的两个问题：限制和性能：
关于启用代理的实体的限制：当实体框架以DB First方法生成类时，类必须遵循以启用变更跟踪代理的规则并不那么重要，因为它们根本不是限制性的。 谁真的关心导航集合是IList还是HashSet？ 只有当应用程序中有设计好的类并且从它们生成表时，谈论这些限制才是明智的。
首先不支持复杂属性。 所以我们可以将它们排除在讨论之外。
关于性能：在已解决的文章以及我迄今为止研究的一些其他实验中，结果并不十分令人信服地拒绝代理以支持快照。 首先，实验在大量的实体10,000上进行。 在您的应用程序中（而不是在数据库中）的批处理过程不可能在大量实体上运行，然而，假定存在更好的方法，例如存储过程。 其次，根据应用程序的类型和需求，例如，当Repository模式被推动和使用时，我们通常处理的实例数量很少; 代理和快照的性能没有区别。 有趣的是，在所研究的实验中，重新为属性重新分配相同的值是代理性能显着失败的唯一情况。 但是，谁真的这样做？ 小心避免重复通知更改跟踪器非常容易。 再次，在这种情况下，当处理大量的实体时会出现重大的问题。
首先，我想知道为什么默认生成的POCO类不符合变更跟踪代理的要求，即标量属性不是虚拟的。
不建议使用更改跟踪代理作为默认更改跟踪策略。 这篇博文中有更详细的解释。 实质上，使用变更跟踪代理的主要原因 - 与基于快照的变更跟踪相比，性能更佳 - 并不总是得到保证 - 有时甚至更糟 - 并且缺点列表比基于快照的变更跟踪更长。
过去，生成POCO实体的T4模板确实将所有属性（包括标量属性）标记为virtual并为基于代理的变更跟踪准备了实体。 由于博客中描述的原因，对于较新的模板（包括用于EF 5的DbContext生成器）进行了更改，正如上面链接的博客帖子下方的注释中所述。 现在，只有导航属性被标记为virtual ，但不是标量属性，这允许延迟加载，但不足以用于更改跟踪代理。
其次，我如何生成启用代理的poco类？
我不知道有任何可用的T4模板会这样做，但修改默认模板以将标量属性也标记为virtual很容易：
在你的项目，你应该有两个文件与.tt扩展： YourModelContainer.tt和YourModelContainer.Context.tt 。 打开YourModelContainer.tt文件。
在这个文件中你会找到一个名为Property的方法：
public string Property(EdmProperty edmProperty)
{
return string.Format(
CultureInfo.InvariantCulture,
"{0} {1} {2} {{ {3}get; {4}set; }}",
Accessibility.ForProperty(edmProperty),
_typeMapper.GetTypeName(edmProperty.TypeUsage),
_code.Escape(edmProperty),
_code.SpaceAfter(Accessibility.ForGetter(edmProperty)),
_code.SpaceAfter(Accessibility.ForSetter(edmProperty)));
}
更改行...
Accessibility.ForProperty(edmProperty),
...至...
AccessibilityAndVirtual(Accessibility.ForProperty(edmProperty)),
而已。
只要提到它，如果您不熟悉它，但有第二种数据库优先方法可用，那就是将现有数据库逆向工程化为代码优先模型。 这种方法根本不使用T4模板，而是使用Fluent API映射创建Code-First模型和上下文。 如果您想定制和扩展模型类（您也可以手动添加virtual修改器），并在未来继续使用Code-First工作流（和代码优先迁移）来更新和演进数据库模式，这将非常有用。