如何从现有数据库生成POCO代理

Question

我最近切换到Entity Framework 5.现在,我想从现有数据库生成POCO类,我还需要延迟加载和更改跟踪.因此,所有标量属性都应该是虚拟的以及导航属性.

添加新的ADO.Net实体数据模型以.edmx文件和其他一些.cs和.tt文件结尾.

首先,我想知道为什么生成的POCO类默认不符合变更跟踪代理的要求,即标量属性不是虚拟的.

其次,如何生成支持代理的poco类？

PS:我接受了Slauma的答案是迄今为止最好和唯一的答案,但我不同意它的第一部分.这是我的论点

Slauma讨论了代理的两个问题:限制和性能:

• 关于启用代理的实体的限制:当实体框架在DB First方法中生成类时,类必须遵循以启用更改跟踪代理的规则并不是那么重要,因为它们根本不是限制性的.谁真正关心导航集是IList还是HashSet？只有当应用程序中存在perior设计类并且要从中生成表时,才能理解这些限制.

• DB首先不支持复杂属性.所以我们可以将它们从讨论中排除.

• 关于性能:在所讨论的文章以及我迄今为止研究的其他一些实验中,结果并不是非常有说服力地拒绝代理以支持快照.首先,实验是在大量实体(即10,000)上完成的.应用程序(不在数据库中)中的批处理过程对大量实体起作用并不是不可能的,但是假设有更好的方法,例如存储过程.其次,根据应用程序的类型和需求,我们通常会处理少量的entites,例如当Repository模式被强制使用时; 代理和快照的性能没有区别.有趣的是,在已解决的实验中,重新为属性重新分配相同的值是代理性能显着失败的唯一情况.但谁真的这样做？小心避免反复通知更改跟踪器非常容易.同样,在这种情况下,当处理大量的entites时会出现重大问题.

Answer 1

首先，我想知道为什么默认生成的 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 模板，而是创建一个 Code-First 模型和一个具有 Fluent API 映射的上下文。如果您想要自定义和扩展模型类（您也可以virtual手动添加修饰符）并在将来继续使用代码优先工作流程（和代码优先迁移）来更新和发展数据库架构，那么它会非常有用。