Почему “Fixup” необходим для Персистентности Неосведомленный POCO's в EF 4?

Одной из очень ожидаемых функций Платформы Объекта 4 является способность использовать ПОСТЕПЕННО (Простые Объекты CLR) в Персистентности Неосведомленный способ (т.е. они не "знают", что сохраняются с Платформой Объекта по сравнению с некоторым другим механизмом).

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

Конкретно я обращаюсь к региону Ассоциации Fixup, это сгенерировано 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. Другие общие неосведомленные персистентности ORMs не имеют подобных ограничений.

Действительно ли это происходит из-за фундаментальных проектных решений в EF? Находится на одном уровне часть ненезнания здесь для пребывания даже в более поздних версиях EF? Существует ли умный способ скрыть эту зависимость от персистентности от ПОСТЕПЕННО разработчик?

Как это удается на практике, от начала до конца? Например, я понимаю, что поддержка была только недавно добавлена для ObservableCollection (который необходим для Silverlight и WPF). Есть ли глюки в других программных слоях от конструктивных требований EF-compatible, ПОСТЕПЕННО возражает?

15
задан Nelson Reis 18 March 2011 в 09:22
поделиться

1 ответ

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

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

Fixup

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

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

16
ответ дан 1 December 2019 в 04:17
поделиться
Другие вопросы по тегам:

Похожие вопросы: