为什么EF4中的PersistenceIgnorantPOCO需要“修复”？EntityFramework4备受期待的功能之一是能够以一种不了解持久性的方式使用POCO（普通旧CLR对象）（即，它们“不知道”它们是通过EntityFramework持久化的，而不是其他机制）.我正在尝试弄清楚为什么我必须执行关联的修正并在我的“正常”业务对象中使用FixupCollection。这个要求似乎暗示业务对象毕竟不能完全忽略持久性机制（事实上，“fixup”这个词听起来像是需要修复/更改以适应所选择的持久性机制）。具体来说，我指的是由ADO.NETPOCO实体生成器生成的关联修复区域，例如：#regionAssociationFixupprivatevoidFixupImportFile(ImportFilepreviousValue){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团队博客）修复为实体上的每个导航属性编写修复方法，并在其值更改时从导航属性的设置器中调用它。其目的是确保双向关系的每一端都与另一端保持同步。例如，在Customer和Order之间的一对多关系中，无论何时设置Order.Customer，fixup方法都会确保Order在Customer的Orders集合中。它还保留了相应的外键属性，即。Order.CustomerID与新客户的主键(ID)值同步。如果独立于EF堆栈使用POCO实体，例如针对未写入数据库的测试编写测试，则此逻辑很有用。Fixup确保对象图的连接方式与使用EF时相同。修复方法编写起来有点复杂，因此如果您计划在EF独立场景中使用实体，则自动生成它们非常有用。此外，请查看实体框架第1部分中的这个POCO，其中还有一些部分介绍了修复的内容以及它们需要什么。以上是C#学习教程：为什么EF4中的PersistenceIgnorantPOCO需要“Fixup”？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
