Почему «Fixup» необходим для постоянных невежественных POCO в EF 4? - PullRequest
Новая
       18

Почему «Fixup» необходим для постоянных невежественных POCO в EF 4?

15 голосов
/ 31 мая 2010

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

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

В частности, я имею в виду регион Исправления ассоциации, созданный ADO.NET POCO Entity Generator , например ::

    #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 Ответ

16 голосов
/ 31 мая 2010

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

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

Fixup

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

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

...