Шаблоны использования / варианты использования для DI или когда начать использовать его

Question

Я не уверен, для каких случаев следует использовать DI в приложении.Я знаю, что инъекционные сервисы, такие как PlaceService или CalculationService и т.д., подходят очень хорошо, но я должен также создавать свои доменные объекты с DI, как User?Что если User имеет только один конструктор, который требует имя и фамилию.Это можно решить с помощью DI?

Должен ли я использовать DI для создания экземпляров для интерфейсов Set / List или это просто перебор?

В основном я использую guice.

Answer 1

Ответ от ig0774 является хорошей отправной точкой. Кроме того, я хотел бы предложить следующее правило:

В терминологии Domain-Driven Design вы должны использовать DI для услуг , но не для сущностей или объектов значений .

Другими словами, DI хорошо сочетается с концептуально долгоживущими объектами без состояния, из которых обычно используется один или известное число.

Answer 2

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

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

Guice имеет конкретное решение для типа проблемы, создаваемой такими объектами, как ваш пользовательский объект, под названием AssistedInject , хотя подобные вещи также возможны с другими облегченными контейнерами или с использованием чего-то, что использует шаблоны компоновщика или адаптера.