为什么是“Fixup”需要持久性无知POCO在EF 4？ [英] Why is "Fixup" needed for Persistence Ignorant POCO's in EF 4?

问题描述

实体框架4的一个令人期待的功能之一是能够以持久性无知的方式使用POCO（Plain Old CLR Objects）（即他们不知道他们被Entity Framework持久化）一些其他机制）。

我试图围绕为什么需要执行关联fixup并在我的普通业务对象中使用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（本）; 
} 
 if（ImportFileId！= ImportFile.Id）
 {
 ImportFileId = ImportFile.Id; 
} 
} 
} 
 
 #endregion 
  

以及FixupCollection的使用。其他常见的持久性无知ORM没有类似的限制。

这是由于EF中的基本设计决定吗？这里的某种程度的无知在EF甚至在后期的版本？有没有一个聪明的方法来隐藏来自POCO开发人员的持久性依赖性？

这在实践中如何实现端对端？例如，我知道最近才为ObservableCollection添加了支持（这是Silverlight和WPF需要的）。有没有从EF兼容的POCO对象的设计要求到其他软件层的错误？

解决方案

找到几个解释 - 检查出来！

POCO模板代码生成选项（EF团队博客）

Fixup

一个实体的每个
导航属性编写一个修正方法，
从
导航属性的设置器调用，每当它价值
更改。 其目的是确保双向
关系中的
与
的其他关系保持同步。例如，在一对多
$ b在Cutomer和
之间的关系订单，只要设置Order.Customer，
fixup方法确保
订单在客户的订单
集合中。它还保持
对应的外键属性
viz。 Order.CustomerID与
新客户的主键（ID）值同步。
如果POCO
实体独立于
EF堆栈使用，那么这个逻辑可能是有用的，比如为
数据库编写测试
。 Fixup确保
对象图以相同的
方式连接，您可以使用
与EF一起使用。 Fixup方法是一个
复杂的写入，因此如果
计划在EF独立场景中使用实体
，那么它们是自动生成的。 / p>

还要查看这个实体框架第1部分中的POCO ，它还有一些关于什么修复的部分以及他们需要什么。

One of the much-anticipated features of Entity Framework 4 is the ability to use POCO (Plain Old CLR Objects) in a Persistence Ignorant manner (i.e. they don't "know" that they are being persisted with Entity Framework vs. some other mechanism).

I'm trying to wrap my head around why it's necessary to perform association fixups and use FixupCollection in my "plain" business object. That requirement seems to imply that the business object can't be completely ignorant of the persistence mechanism after all (in fact the word "fixup" sounds like something needs to be fixed/altered to work with the chosen persistence mechanism).

Specifically I'm referring to the Association Fixup region that's generated by the ADO.NET POCO Entity Generator, e.g.:

    #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

as well as the use of FixupCollection. Other common persistence-ignorant ORMs don't have similar restrictions.

Is this due to fundamental design decisions in EF? Is some level of non-ignorance here to stay even in later versions of EF? Is there a clever way to hide this persistence dependency from the POCO developer?

How does this work out in practice, end-to-end? For example, I understand support was only recently added for ObservableCollection (which is needed for Silverlight and WPF). Are there gotchas in other software layers from the design requirements of EF-compatible POCO objects?

解决方案

Found a few explanations - check them out!

POCO Template Code Generation Options (EF team blog)

Fixup

A fixup method is written for every navigation property on an entity and is called from the setter of the navigation property whenever its value changes. Its purpose is to ensure that each end of a bidirectional relationship stays in sync with the other. For example, in a one-to-many relationship between Cutomer and Order, whenever Order.Customer is set, the fixup method ensures that the Order is in the Customer’s Orders collection. It also keeps the corresponding foreign key property viz. Order.CustomerID in sync with the new Customer’s primary key (ID) value. This logic can be useful if the POCO entities are used independently of the EF stack, like for writing tests against them which don’t hit the database. Fixup ensures that the object graph is connected in the same way as you would expect while using them with EF. Fixup methods are a bit complex to write and hence it is useful to have them auto-generated if you are planning on using the entities in an EF independent scenario.

And also check out this POCO in the Entity Framework Part 1 which also has some sections on what fixups are and what they're needed for.

这篇关于为什么是“Fixup”需要持久性无知POCO在EF 4？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！