Агрегатная корневая поддержка в Entity Framework

Как мы можем рассказать Entity Framework о Сростки?

  1. при сохранении агрегата сохраните объекты в агрегате
  2. при удалении агрегата удалите объекты внутри агрегата
  3. поднимите ошибку параллелизма, когда два разных пользователя пытаются изменить две разные сущности в одном aggreate
  4. загружая компосит, обеспечьте последовательный пункт-В-времени взгляд компосита даже если некоторая задержка времени, прежде чем мы получим доступ ко всем сущностям в aggregate

(Entity Framework 4.3.1 Код Первый)

2 ответов


EF предоставляет функции, которые позволяют определять ваши агрегаты и использовать их:

  1. Это самая болезненная часть. EF работает с графами сущностей. Если у вас есть сущность, подобная накладной, и у этой сущности есть коллекция связанных сущностей InvoiceLine, вы можете подойти к ней как к aggregate. Если вы находитесь во вложенном сценарии, все работает как ожидалось, но в отдельном сценарии (либо aggregate не загружается EF, либо загружается другим экземпляром контекста), вы должны прикрепить экземпляр aggregate to context и скажите ему, что именно вы изменили = установить состояние для каждой сущности и Независимой ассоциации в графе объектов.
  2. это обрабатывается cascade delete - если у вас загружены связанные объекты, EF удалит их, но если вы этого не сделаете, вы должны иметь cascade delete, настроенный на отношение в базе данных.
  3. это обрабатывается токенами параллелизма в базе данных-чаще всего либо меткой времени, либо столбцами rowversion.
  4. вы должны либо используйте нетерпеливую загрузку и загрузите все данные вместе в начале (=согласованная точка зрения), либо вы будете использовать ленивую загрузку, и в таком случае у вас не будет согласованной точки зрения, потому что ленивая загрузка загрузит текущее состояние отношений, но не обновит другие части aggregate, которые вы уже загрузили (и я считаю это убийцей производительности, если вы попытаетесь реализовать такое обновление с EF).

я писал GraphDiff специально для этой цели. Это позволяет определить "агрегатную границу" при обновлении, предоставляя свободное отображение. Я использовал его в тех случаях, когда мне нужно было передавать отдельные графики сущностей взад и вперед.

например:

// Update method of repository
public void Update(Order order)
{
    context.UpdateGraph(order, map => map
        .OwnedCollection(p => p.OrderItems);
}

выше будет сказано Entity Framework обновить сущность order, а также объединить коллекцию OrderItems. Сопоставление таким образом позволяет нам гарантировать, что Entity Framework только управляет графом в пределах, которые мы определяем на агрегате, и игнорирует все остальные свойства. Он поддерживает оптимистическую проверку параллелизма всех сущностей. Он обрабатывает гораздо более сложные сценарии, а также может обрабатывать ссылки на обновление во многих сценариях (через AssociatedCollections).

надеюсь, это может быть полезно.