相关疑难解决方法(0)

实体框架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对象的设计要求？