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 Template Code Generation Options（EF团队博客）

Fixup时

为每个人编写一个修复方法   实体上的导航属性和   是从安装者的召唤者   导航属性何时其价值   变化。 其目的是确保这一点   双向的每一端   关系与...保持同步   其他。例如，在一对多中   Cutomer与   订单，每当Order.Customer设置，   fixup方法确保了   订单在客户订单中   采集。它也保持着   相应的外键属性   即Order.CustomerID与。同步   新客户的主键（ID）值。   如果POCO，这个逻辑可能很有用   实体独立使用   EF堆栈，就像编写测试一样   反对他们没有击中   数据库。 Fixup确保了   对象图连接在一起   正如您在使用时所期望的那样   他们与EF。修复方法有点   复杂的写作，因此它   如果有自动生成它们很有用   您正计划使用实体   在EF独立场景中。

还可以查看这个POCO in the Entity Framework Part 1，其中还有一些关于修正是什么以及它们需要什么的部分。

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

1 个答案: