Сущности зависят от абстракций репозиториев

Агрегаты представляют собой границу согласованности, поэтому никогда не должно возникать необходимости в ленивой загрузке связанных данных, поскольку агрегат в целом должен всегда быть согласованным. Все объекты, принадлежащие агрегату, не должны существовать сами по себе. Если у вас есть объект с собственным жизненным циклом, его необходимо удалить из совокупности.

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

Внедрение репозиториев или сервисов в объекты, как правило, не лучшая идея. Следует отдавать предпочтение механизму двойной диспетчеризации.

Но в вашем случае я бы все же попытался не откладывать загрузку.

Рассмотрите возможность использования прокси, который является подклассом Post, переопределяет метод getComments(). Вставьте прокси-сервер с CommentRepository и получите к нему доступ в переопределенном методе getComment().

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

Во-первых, вы должны отделить понятие предметной области от деталей реализации. Шаблон Agreagate — это то, как организовать ваш домен, а отложенная загрузка — это деталь реализации.

Кроме того, я не согласен с @Eben Roux по поводу несоответствия решений. Ленивая загрузка, на мой взгляд, ничему не противоречит. Я выражаю почему.

Ленивая загрузка себя

Чтобы понять, как можно реализовать ленивую загрузку, вы можете обратиться к шаблону PoEAAA Мартина Фаулера 'Lazy loading'. Для меня шаблон прокси - лучшее решение. Кроме того, важно, что большинство современных ORM поддерживает ленивую загрузку, НО для модели данных (а не для модели предметной области).

Рекомендуется разделить модель данных и модель предметной области и использовать репозитории, чтобы скрыть это преобразование:

Разделенные модели предметной области и данных

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

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

public class Post {

    private ICommentsRepository _commentsRepository;

    private IList<Comments> _comments;

    //necessary to perform lazy loading (repository always wroks with ids)
    private IList<int> _commentIds;

    //realize lazy loading
    ...
}

есть проблемы:

1. Ваша модель теперь становится непонятной. Он содержит «техническую» информацию, такую ​​как _commentIds.
2. Как только вы хотите определить ICommentsRepository, вы заявляете, что Comment является совокупным корнем. Если мы введем паттерн агрегации в модель предметной области, репозитории должны создаваться только для корней агрегации. Таким образом, это означает, что Comment и Post являются разными совокупными корнями. И возможно, что это не то, что вы хотите.

Есть лучшее решение:

public interface ICommentList {
...
}

public class CommentList : ICommentList {
...
}

public class CommentListProxy : ICommentList {

   private CommentList _realCommentList;

   private IList<int> _commentIds;

   //realize lazy loading here using ORMs capabilities! 
   //don't use repository here!

}

public class Post {

   private ICommentList _commentList;

   ...
}

Почтовый репозиторий инициирует поле _commentList с прокси-объектом. Также необходимо сказать:

1. CommentListProxy относится к уровню модели данных, а не к модели предметной области. Он использует возможности ORM для реализации ленивой загрузки.
2. и поэтому не использует репозитории, поэтому вы можете рассматривать CommentList как часть совокупности Post.

Единственный возможный недостаток этого подхода заключается в неявных запросах к базе данных при работе с объектами предметной области. Это должно быть понятно пользователям класса Post.

Умные ORM

Наконец, есть виды ORM, которые позволяют вам использовать одну и ту же модель как для домена, так и для данных. Он реализует ленивую загрузку для модели предметной области так же, как и для модели данных. Взгляните на DataObjects.Net. Для некоторых случаев это хорошее решение.