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

Question

Некоторые программисты получают доступ к своим контейнерам IoC с помощью статических методов класса.Это просто предпочтение или требование?

Если мой пользовательский провайдер членства нуждается в DataContext, как я могу вставить свой DataContext в него без статического класса?

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

Если предпочтителен статический способ, должен ли я хранить свой базовый контейнер в одноэлементной области видимости и инициализировать его в Global.asax и всегда получать доступ к своему контейнеру через статический класс?

Answer 1

Статический Сервисный локатор просто никогда не является хорошей идеей .Модель поставщика ASP.NET страдает от антишаблонов Constrained Construction , а также множества других проблем *1005*.Лучше избегать, если это вообще возможно (обычно это так).

Answer 2

Самая распространенная причина отказа от статического доступа IoC или шаблона Service Locator заключается в том, что он добавляет дополнительную зависимость, которая усложняет модульное тестирование.

Вы должны использовать инъекцию конструктора, где это возможно.

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

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

Answer 3

Не требуется, чтобы контейнеры IoC были статичными, на самом деле вы можете создавать столько, сколько пожелаете - все зависит от того, что вам нужно. Как вы, вероятно, выяснили, в некоторых случаях вам нужен статический контейнер.