为什么EF 4中的Persistence Ignorant POCO需要“Fixup”？
entity framework4备受期待的function之一是能够以持久性无知方式使用POCO（普通旧CLR对象）（即，他们不“知道”它们与entity framework相对于其他机制持久化）。
我试图解决为什么必须执行关联修正并在我的“普通”业务对象中使用FixupCollection。 这个要求似乎意味着业务对象毕竟不能完全忽略持久性机制（事实上，“fixup”这个词听起来像需要修复/改变以适应所选择的持久性机制）。
具体来说，我指的是由ADO.NET POCO实体生成器生成的Association Fixup区域，例如：
#region Association Fixup private void FixupImportFile(ImportFile previousValue) { if (previousValue != null && previousValue.Participants.Contains(this)) { previousValue.Participants.Remove(this); } if (ImportFile != null) { if (!ImportFile.Participants.Contains(this)) { ImportFile.Participants.Add(this); } if (ImportFileId != ImportFile.Id) { ImportFileId = ImportFile.Id; } } } #endregion 以及FixupCollection的使用。 其他常见的持久性无知ORM没有类似的限制。
这是由于EF的基本设计决定吗？ 即使在EF的后期版本中，是否存在某种程度的非无知？ 是否有一种聪明的方法可以隐藏POCO开发人员的持久性依赖性？
这在实践中如何实现，端到端？ 例如，我理解最近才为ObservableCollection添加了支持（Silverlight和WPF需要它）。 其他软件层是否存在EF兼容POCO对象的设计要求？
找到一些解释 – 检查出来！
POCO模板代码生成选项 （EF团队博客）
修理
为实体上的每个导航属性编写fixup方法，并在其值更改时从导航属性的setter调用。 其目的是确保双向关系的每一端与另一端保持同步。 例如，在Cutomer和Order之间的一对多关系中，每当设置Order.Customer时，fixup方法都会确保Order位于Customer的Orders集合中。 它还保留相应的外键属性即。 Order.CustomerID与新Customer的主键（ID）值同步。 如果POCO实体独立于EF堆栈使用，则此逻辑非常有用，例如针对未写入数据库的测试编写测试。 Fixup确保对象图以与使用EF时相同的方式连接。 修复方法的编写有点复杂，因此如果您计划在EF独立方案中使用实体，则自动生成它们很有用。
此外，还可以在entity framework第1部分中查看此POCO，其中还包含一些关于修正是什么以及它们需要什么的部分。