DDD репозитории как синглтоны?

Question

Быстрый вопрос: будет ли хорошей или плохой идеей реализовывать мои репозитории в стиле доменного дизайна в виде синглетонов? Почему?

Или мне следует использовать контейнер инжектора зависимостей для управления моими репозиториями и решить, являются ли они синглетонами или нет?

Я все еще читаю DDD Quickly и хотел бы увидеть несколько хороших примеров репозитория.

Answer 1

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

Используя

UserRepository.Instance.Find(userId);

вы создаете барьер для тестирования.

Если ваши репозитории передаются в службы с помощью Constructor Injection, то вы также можете легко заменить их на макеты.

Answer 2

Я видел несколько способов сделать это.

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

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

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

Answer 3

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

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

Насколько я понимаю, гораздо чище создать хранилище, которое гарантирует, что у вас есть только одна сущность вместо многих. Это ответственность репозитория, а не организации, если вы хотите, чтобы ваш код отвечал принципу единственной ответственности .

Answer 4

Допустим, у меня действительно огромный проект, и я хочу добавить новый сервис, скажем, это будет какой-то аппаратный представитель в моей системе. Я хочу, чтобы этот сервис был доступен через многие классы, я хочу быть уверенным, что существует только один экземпляр сервиса или слой, который контролирует доступ к сервису. Внедрение этого сервиса через всю мою систему (более 200 классов) будет большой работой. Для меня "Singleton" или какой-то "Service Locator" хорошо подходит для этой задачи.

Answer 5

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