Как метод действия ASP.NET MVC может получить доступ к дочерним объектам совокупного корня?

Question

У меня проблемы с пониманием того, как можно получить доступ к дочерним объектам совокупного корня.Из ответов на мой предыдущий вопрос теперь я понимаю, что мне нужно идентифицировать совокупные корни моей модели, а затем настраивать только репозитории, которые обрабатывают эти корневые объекты.

Так, скажем, у меня есть объект Order, который содержит Предметы.Элементы должны существовать в пределах и порядка, так что порядок является совокупным корнем.Но что, если я хочу включить в свой сайт страницу сведений OrderItem?URL-адрес этой страницы может быть чем-то вроде / Order / ItemDetails / 1234, где 1234 - это идентификатор OrderItem.Тем не менее, для этого потребуется, чтобы я получал Item напрямую по идентификатору, и, поскольку он не является агрегированным корнем, у меня не должно быть OrderItemRepository, которое может извлекать OrderItem по ID.a Orders означает, что OrderItem на самом деле не является совокупностью Order, а является другим совокупным корнем?

Answer 1

Конечно, я не знаю ваших бизнес-правил, но я не могу вспомнить случай, когда у вас был бы заказ, в котором нет заказа. Не говоря о том, что вы не захотите «работать с одним» сам по себе, но у него все еще должен быть приказ, иммо, и этот порядок как бы отвечает за отношения; например Вы представляете все это, добавляя или удаляя элементы из заказа.

В подобных ситуациях мне, как правило, по-прежнему требуется доступ к товарам через заказ. Это довольно легко настроить, в URL я бы просто сделал / order / 123 / item / 456. Или, если порядок элементов сохранен / важен (что обычно сохраняется по крайней мере косвенно через порядок ввода), вы можете сделать / order / 123 / item / 1, чтобы получить первый элемент в заказе.

Затем в контроллере я просто получаю заказ из репозитория OrderReader и затем оттуда получаю доступ к соответствующему элементу.

Все сказанное, я согласен с Арнисом, что вам не всегда нужно следовать этому образцу. Это в каждом конкретном случае, что вы должны оценить компромиссы, прежде чем делать это.

Answer 2

В вашем случае я бы получал OrderItem напрямую по URL /OrderItem/1234.

Лично я не пытаюсь абстрагировать постоянство (я не использую шаблон репозитория). Кроме того - я не следую за репозиторием по принципу совокупного корня. Но я изолирую модель предметной области от постоянства.

Основная причина этого в том, что почти невозможно полностью абстрагировать механизмы персистентности. Это дырявая абстракция (например, попробуйте указать энергичную / ленивую загрузку для ORM, которая находится под API-интерфейсом хранилища без загрязнения).

Другая причина - не имеет большого значения, каким образом вы сообщаете данные. Репортажная часть скучна и относительно неважна. Реальная ценность приложения в том, что оно может сделать - автоматизация процессов. Поэтому гораздо важнее, как ваше приложение ведет себя, как ему удается оставаться согласованным, как взаимодействуют объекты и т. Д.

Обдумывая эту проблему, хорошо помнить Закон Деметры . Суть в том, что его следует применять только , если мы явно хотим скрыть внутренности. В вашем случае - мы не хотим скрывать позиции заказа.

Итак, используя тот факт, что мы знаем, что идентификаторы сущностей являются глобально уникальными (в отличие от уникальных только в контексте Порядка), это всего лишь кратчайший путь, и нет ничего плохого в их непосредственном извлечении.

---

Интересно, что это можно продвинуть вперед.
Даже инкапсуляция поведения может и тоже быть ослаблена .

например. - имеет смысл иметь orderItem.EditComments("asdf"), чем order.EditOrderItemComments(order.OrderItems[0], "asdf").