Как моделировать подмножества межобъектных отношений

Question

Я новичок в работе с моделями доменов, так что простите, что задаю элементарный вопрос.

Если объект домена имеет отношение 1-много к другому объекту домена, но логика, которая использует первый объект, работает только с подмножеством объектов, связанных с этими объектами, каков наилучший способ раскрыть это подмножество?

Например, скажем, Персона связана со многими Орденами, но некоторая внешняя логика должна проверять только «Отправленные» Ордена, связанные с Персоналом. Должен ли Person иметь свойство DispatchedOrders вместе с другими свойствами для других подмножеств (например, CompletedOrders и т. Д.) Или это плохой дизайн? Предположим, по соображениям производительности я не могу отфильтровать объекты в памяти и должен использовать SQL, чтобы получить только интересующее меня подмножество.

Спасибо

Answer 1

Если вы используете SQL для поиска интересующего вас набора, вы попадаете в идеальный мир. Реляционные запросы - все о поиске такого рода вещей. Найдите идеальный запрос, а затем просто выясните, каков класс кортежей результатов, т. Е. Объект для каждого кортежа результатов, и обработайте их соответствующим образом.

В вашем примере вам нужен набор «Отправленных заказов», к которому прикрепляется любая необходимая информация о человеке.

Answer 2

Я думаю, у вас правильная идея - DispatchedOrders точно скажет мне, какую коллекцию объектов вы мне возвращаете. Как сказал Курт, вы находитесь в хорошем положении, поскольку вы можете использовать хранимую процедуру SQL для извлечения ваших данных.

Одно предостережение - убедитесь, что домен соответствует бизнес-процессу и не является интерполяцией понимания вами этого процесса. То есть - почему человек имеет первенство над порядком и в какой угол вы попадаете, когда создаете другие объекты. Содержит ли элемент позиции также порядок, и это приводит к раздутию объекта? Обсуждения с вашим клиентом должны помочь сформировать ответ.

Роб Конери из SubSonic Fame имеет хорошее обсуждение этих типов проблем . Стоит послушать.