Почему требуется исправление для POCO, не знающих персистентности, в EF 4?

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

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

В частности, я имею в виду область исправлений ассоциации, созданную 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?


c# entity-framework-4 poco
person Eric J.    schedule 31.05.2010    source источник

Ответы (1)


arrow_upward
17
arrow_downward

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

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

Исправить

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

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

person marc_s    schedule 31.05.2010
comment
Вторая ссылка указывает в части In Beta1 of Entity Framework 4.0, you do not get automatic relationship fix-up in this case with POCO entities.. Интересно, означает ли это, что однажды произойдет автоматическое исправление. - person Eric J.; 31.05.2010
comment
Ссылка сейчас не работает .. якобы переносится. - person madannes; 08.09.2016