添加新的ADO.Net实体数据模型以.edmx文件和其他一些.cs和.tt文件结尾.
首先,我想知道为什么生成的POCO类默认不符合变更跟踪代理的要求,即标量属性不是虚拟的.
PS：我接受了Slauma的答案是迄今为止最好和唯一的答案,但我不同意它的第一部分.这是我的论点
Slauma谈到了代理的两个问题：限制和性能：
>关于启用代理的实体的限制：
当实体框架在DB First方法中生成类时,类必须遵循以启用更改跟踪代理的规则并不是那么重要,因为它们根本不是限制性的.谁真正关心导航集是IList还是HashSet？只有当应用程序中存在perior设计类并且要从中生成表时,才能理解这些限制.
>首先不支持DB中的复杂属性.所以我们可以将它们从讨论中排除.
>关于性能：
在the addressed article以及我迄今为止研究过的其他一些实验中,结果并不是非常有说服力地拒绝代理以支持快照.首先,实验是在大量实体a.k.a 10,000上完成的.应用程序(不在数据库中)中的批处理过程对大量实体起作用并不是不可能的,但是假设有更好的方法,例如存储过程.
其次,根据应用程序的类型和需求,我们通常会处理少量的entites,例如当Repository模式被强制使用时;代理和快照的性能没有区别.
有趣的是,在已解决的实验中,重新为属性重新分配相同的值是代理性能显着失败的唯一情况.但谁真的这样做？小心避免反复通知更改跟踪器非常容易.同样,在这种情况下,当处理大量的entites时会出现重大问题.
解决方法
Firstly,I wonder why the generated POCO classes by default do not
meet the requirements of change tracking proxy,i.e scalar properties
are not virtual.
建议不要使用更改跟踪代理作为默认更改跟踪策略.它在this blog post中有更详细的解释.实质上,使用更改跟踪代理的主要原因 – 与基于快照的更改跟踪相比,性能更好 – 并不总是得到保证 – 有时甚至更糟 – 并且缺点列表比快照更长基于变更跟踪.
过去,生成POCO实体的T4模板确实将所有属性(包括标量属性)标记为虚拟,并为基于代理的变更跟踪准备实体.由于博客中描述的原因,对于较新的模板已经进行了更改,包括用于EF 5的DbContext Generator,如上面链接的博客文章下面的this comment中所述.现在,只有导航属性被标记为虚拟属性,而不是标量属性,这允许延迟加载但不足以用于更改跟踪代理.
Secondly,how can I generate proxy-enabled poco classes?
我不知道有任何可用的T4模板,但是很容易修改默认模板以将标量属性标记为虚拟：
>在您的项目中,您应该有两个扩展名为.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)),
而已.
只是提一下,如果您不熟悉它,但是有第二种可用的数据库优先方法,即Reverse Engineering an existing database to a Code-First model.这种方法根本不使用T4模板,而是创建了Code-First模型,使用Fluent API映射的上下文.如果要自定义和扩展模型类(也可以手动添加虚拟修饰符)并在将来继续使用代码优先工作流(和代码优先迁移)来更新和发展数据库模式,这将非常有用.
