Почему "Fixup" необходим для Persistence Ignorant POCO в EF 4?

Одной из наиболее ожидаемых особенностей Entity Framework 4 является способность использовать POCO (простые обычные объекты CLR) в методе ненасилия настойчивости (т.е. они не "знают", что они сохраняются с Entity Framework vs. другой механизм).

Я пытаюсь окутать голову, почему необходимо выполнить фиксацию ассоциации и использовать FixupCollection в моем "обычном" бизнес-объекте. Это требование, по-видимому, подразумевает, что бизнес-объект не может быть полностью не осведомлен о механизме сохранения в конце концов (на самом деле слово "fixup" звучит так, будто что-то нужно исправлять/изменять для работы с выбранным механизмом сохранения).

В частности, я имею в виду область Fixup ассоциации, которая генерируется генератором Entity Entity ADO.NET, например:

    #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?

Ответ 1

Нашли несколько объяснений - проверьте их!

Параметры генерации кода шаблона POCO (блог группы EF)

Fixup

Метод фиксации записывается для каждого навигационное свойство на объекте и вызывается из сеттера навигационного свойства, когда его значение изменения. Его цель - обеспечить, чтобы каждый конец двунаправленного отношения находятся в синхронизации с прочее. Например, в режиме "один ко многим" отношения между Cutomer и Заказ, когда установлен Order.Customer, метод fixup гарантирует, что Заказ находится в Заказе клиентов коллекция. Он также соответствующее свойство внешнего ключа а именно Order.CustomerID в синхронизации с новое значение первичного ключа клиента (ID). Эта логика может быть полезна, если POCO объекты используются независимо от EF-стек, как и для написания тестов против них, которые не попали в база данных. Fixup гарантирует, что граф объектов связан в одном и том же как вы ожидали бы при использовании их с EF. Методы Fixup немного сложный для записи, и, следовательно, это полезно, чтобы они были автоматически сгенерированы, если вы планируете использовать объекты в независимом от EF сценарии.

И также ознакомьтесь с этим POCO в Entity Framework Part 1, в котором также есть некоторые разделы о том, какие исправления и какие они нужны для.