为什么EF 4中的Persistence Ignorant POCO需要"Fixup"？

Question

实体框架4备受期待的功能之一是能够以持久性无知方式使用POCO(普通旧CLR对象)(即他们不"知道"它们与实体框架相对于其他机制持久化).

我试图解决为什么必须执行关联修正并在我的"普通"业务对象中使用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对象的设计要求？

Answer 1

找到一些解释 - 检查出来!

POCO模板代码生成选项(EF团队博客)

修理

为实体上的每个导航属性编写fixup方法,并在其值更改时从导航属性的setter调用.其目的是确保双向关系的每一端与另一端保持同步.例如,在Cutomer和Order之间的一对多关系中,每当设置Order.Customer时,fixup方法都会确保Order位于Customer的Orders集合中.它还保留相应的外键属性即.Order.CustomerID与新Customer的主键(ID)值同步.如果POCO实体独立于EF堆栈使用,则此逻辑非常有用,例如针对未写入数据库的测试编写测试.Fixup确保对象图的连接方式与使用EF时的方式相同.修复方法的编写有点复杂,因此如果您计划在EF独立方案中使用实体,则自动生成它们很有用.

还可以在实体框架第1部分中查看此POCO,其中还有一些关于修正是什么以及它们需要什么的部分.