Аннотация завод шаблон на вершине IoC?

Question

Я решил использовать принципы IoC в более крупном проекте. Тем не менее, я хотел бы получить что-то прямое, что беспокоило меня в течение длительного времени. Вывод, который я придумал, заключается в том, что контейнер IoC является архитектурным шаблоном, а не шаблоном проектирования. Другими словами, ни один класс не должен знать о его присутствии, и сам контейнер должен использоваться на уровне приложения, чтобы сшить все компоненты. По существу, он становится опцией, на вершине хорошо продуманной объектно-ориентированной модели. Сказав это, как можно получить доступ к разрешенным типам без разбрызгивания контейнеров IoC по всему месту (независимо от того, они абстрагированы или нет)? Единственный вариант, который я вижу здесь, - использовать абстрактные фабрики, которые используют контейнер IoC для разрешения конкретных типов. Это должно быть достаточно просто, чтобы поменяться местами для набора стандартных фабрик. Это хороший подход? Кто-нибудь здесь использовал его и насколько хорошо он работал на вас? Есть ли что-нибудь еще?

Спасибо!

Answer 1

Как вы уже выяснили, сам процесс инжекции (DI) сам по себе является лишь набором узоров и методов.

В корне приложения мы подключаем все необходимые графы объектов. Это место называется Состав Корень, и мы можем использовать контейнер DI, чтобы сделать это для нас, или мы можем сделать это вручную (Poor's DI).

Дело в том, что в вашем приложении есть только одно место, где есть сильная ссылка на конкретную технологию (ваш контейнер DI). Остальная часть приложения блаженно не знают о как объект граф был подключен вверх - все, что имеет значение в том, что все необходимые зависимости были правильно введен (и вы можете использовать Constructor Injection с Null гвардейской, чтобы гарантировать, что это так).

Abstract Factory картина является очень полезный образец, когда дело доходит до DI. В сущности, используйте Abstract Factory, когда:

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

Примеры и дополнительная информация доступна здесь:

• Is there a pattern for initializing objects created via a DI container
• Can't combine Factory/DI
• Which DI container will satisfy this
• Where should I do Injection with Ninject 2+ (and how do I arrange my Modules?)
• Design - Where should objects be registered when using Windsor

Answer 2

В верхней части большей части вашего приложения вам понадобится класс Bootstrap, который загружает контекст IOC. Этот контекст затем предоставит фактически созданные объекты и, следовательно, станет фабрикой.

Но это должно происходить только с очень небольшим количеством объектов, и пользователь вашего класса Bootstrap/Factory должен знать как можно меньше о базовой архитектуре. Например, если вы полностью сконфигурировали объект HTTP-сервера через IOC, и вы хотите запустить его, ваш класс Bootstrap должен только предоставить метод getHttpServer(). Тогда вашему основному методу программы нужно только вызвать Bootstrap.getHttpServer(). Start(), чтобы запустить его.

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