#entity-framework-core #domain-driven-design #automapper-collections-ef-core
Вопрос:
Допустим, у меня есть принципиальная сущность CollectionEntity
и зависимая сущность ItemEntity
на уровне базы данных. У меня также есть эквивалентные Collection
и Item
доменные модели. Я использую EF Core 3.1 и AutoMapper.Коллекции для сопоставления с доменом сущностям. Collection
модели домена также являются совокупным корнем, и операции CRUD Item
моделей выполняются только в Collection
соответствии со стандартами DDD aggregate. Сравнение равенства между доменами и сущностями выполняется с использованием Id
свойства.
Проблема возникает, когда я пытаюсь изменить Item1 с Collection1 на Collection2. Я пробовал два подхода:
- Только обновите Коллекцию2 — Если я просто попытаюсь добавить Элемент1 в Коллекцию2 и сохраню его, это не удастся, потому что элемент1 уже существует в базе данных и связан с коллекцией1. Он идентифицируется по его идентификатору, как упоминалось выше.
- Удалите Элемент1 из Коллекции1, а затем добавьте его в Коллекцию2 — Сначала я удаляю его из Коллекции1, сопоставляю, а затем сохраняю изменения. Это фактически приводит к удалению элемента 1 из базы данных. Затем я добавляю Элемент1 в Collection2 и пытаюсь сопоставить и сохранить его в CollectionEntity2. В этом случае EF терпит неудачу, потому что он пытается обновить ItemEntity1, который был только что удален (это происходит потому, что после сопоставления у ItemEntity1 есть исходный идентификатор, который заставляет EF пытаться обновить). Потенциальным решением было бы установить идентификатор элемента 1 чтобы
0
перед попыткой второй операции сохранения, однако это не является желаемым результатом, так как ссылки на ItemEntity1 либо будут нарушены, либо зависимые объекты будут случайно удалены.
Я пытаюсь обойти эту проблему, вызванную описанной структурой модели предметной области, настолько, что теперь у меня возникает ощущение, что я допустил серьезный недостаток в дизайне. Есть какие-нибудь мысли?