Как избежать внедрения глобального состояния при совместном использовании зависимостей в DI?

Question

Представьте, что вы вводите одно соединение с базой данных в несколько классов обслуживания. Теперь они разделяют то, что по сути является глобальным изменяемым состоянием. Как с этим справляются структуры DI? Они:

• Заморозить зависимость перед внедрением?
• Совместно использовать только неизменяемые объекты?
• Обернуть каждую зависимость в декоратор, чтобы точно указать, от чего зависит?

Я попытался найти это и немного удивлен, что нашел не так много. Не стесняйтесь предоставлять ссылки.

По теме: https://en.wikipedia.org/wiki/Principle_of_least_privilege

Answer 1

Большинство контейнеров DI предоставляют возможность регистрации зависимости в Lifetime. Например, в. net core DI вы можете зарегистрировать службу с тремя разными сроками жизни:

• Singleton: существует только один единственный экземпляр. Все потребители этой службы будут использовать этот экземпляр. Если один потребитель изменяет состояние этой зависимости, все другие потребители увидят это изменение.
• Область действия: существует один экземпляр на область, где областью действия является веб-запрос. Если потребитель изменяет состояние службы с заданной областью действия, все остальные потребители, которые будут запускаться в том же веб-запросе, увидят это изменение.
• Переходный процесс: каждый потребитель использует свой экземпляр службы. 1009 *

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