Я понимаю ваше стремление создавать «просмотры» моделей в домене, но рекомендовал бы против этого. Лично я использую всю сущность внутри домена, независимо от ситуации. Сущность есть сущность, и все, что меньше или больше, просто не чувствует себя чистым. Это не значит, что я не могу использовать ссылку на сущность, чтобы сосредоточиться на использовании элементов в списке.
Сущность не пересекает границу домена в моей реализации. Вместо этого я возвращаю тип DTO, и у меня есть сервисы приложений, которые могут абстрагироваться от него. Это позволяет, например, позволить докладчику сгенерировать правильную модель представления из DTO и предоставить ее представлению. Я не знаю, говорите ли вы об операциях в доменных службах или в службах приложений, но есть несколько вещей, которые вы можете сделать, которые могут быть применены к одному (или к обоим).
Вы можете сделать определенные вещи, чтобы уменьшить потери производительности при работе со всей сущностью в доменных слоях. Одна вещь, на которую стоит обратить внимание, это реализация какой-то реализации вне кэша. Когда объект запрашивается, проверьте, кэшируется ли он. Если это так, верните кэшированную версию. Если это не так, потяните его и затем кэшируйте перед возвратом. Когда сущность обновится, извлеките ее из кэша и выполните обновление. Я специально создал свои конкретные реализации репозитория, чтобы обеспечить кеширование, чтобы облегчить это. Еще одна вещь, которую следует учитывать при использовании такого подхода, заключается в том, что полезно выполнять как можно больше мелких операций. Хотя поначалу это кажется нелогичным, если сущности обычно «получаются» из вашего хранилища данных, легко настроить некоторую регистрацию, чтобы измерить количество попаданий в кеш, чтобы пропустить кеш.
Пройдя полный круг, к вашему вопросу ... Большинство списков, с которыми я имею дело, маленькие, поэтому я несу штраф за загрузку сущности целиком. Предполагая, что большинство вариантов использования будет включать в себя детализацию пользователем одного или нескольких элементов, они предварительно кэшируются из-за реализации вне кэширования. Количество элементов изменчиво, но я обычно применяю этот подход ко всему, что меньше двадцати пяти объектов в списке.
Для больших списков я просто использую идентификаторы. Скорее всего, здесь используется какой-то результат поиска. Например, результаты поиска обычно разбиваются на страницы, и это не вписывается в вышеприведенный шаблон. Вместо этого я использую большой список идентификаторов в качестве скользящего диапазона объектов, которые меня интересуют, и затем я передаю метод GetRangeById (), который есть во всех моих репозиториях, - для того, чтобы нарочно взять список идентификаторов и загрузить их по одному время, чтобы они кэшировались. По сути, это займет больший облегченный список и будет сосредоточен только на той области, которая мне интересна в данный момент времени.
При таком подходе важно понимать, что он хорошо масштабируется. Он может не поддерживать базовый уровень так же быстро, как не кэшированный подход с небольшими наборами данных, но будет работать лучше с большими наборами данных. Здесь присутствуют неявные накладные расходы на производительность, но они также снижаются медленнее, чем стандартная схема загрузки.