IoC, Куда ставить контейнер?

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

Пример: у вашего объекта God есть метод getFoo () и метод getBar (). Объекту A нужен Foo, объекту B - Bar. Если A нужен только один Foo, Foo следует ввести непосредственно в A, а A вообще не должен знать о Боге. Но если A нужно продолжать создавать Foos, ссылка на Бога в значительной степени неизбежна. Но вы можете защитить себя от ущерба, причиняемого, передавая Бога, сужая тип ссылки на Бога. Если вы заставите Бога реализовать FooFactory и дадите A ссылку на FooFactory, реализованную Богом, вы все равно можете написать код в A контекстно-нейтральным способом. Это улучшает возможности повторного использования кода и увеличивает вашу уверенность в том, что изменение Бога не вызовет неожиданных побочных эффектов. Например, при удалении getBar () из God вы можете быть уверены, что класс A не сломается.

НО ... если вы все равно собираетесь иметь все эти интерфейсы, вам, вероятно, лучше написать специализированные фабричные классы и связать все свои объекты вместе, включая фабрики, внутри контейнера, а не обертывать контейнер вообще. Контейнер все еще может настраивать фабрики.

Хотя я ценю явность «специализированных фабрик» и даже использую их сам, это похоже на запах кода в моих собственных проектах, потому что общедоступный интерфейс (маленький «i») постоянно меняется с новой фабрикой и / или новым методом GetX. для каждой реализации. После прочтения Пришло время разрядки контейнеров IoC Джереми Миллера я подозреваю, что дженерики и инъекция самого контейнера - это правильный путь.

Я бы обернул Ninject, StructureMap или Windsor в какой-то интерфейс IServiceLocator, подобный тому, который предлагается в статье Джереми. Затем создайте контейнерную фабрику, которая просто возвращает IServiceLocator в любом месте вашего кода, даже в циклах, как вы изначально предлагали.

IServiceLocator container = ContainerFactory.GetContainer(); 
while( keepLooping )
{
    IExample example = container.GetInstance<IExample>();
    keepLooping = example.DoWork();
}

Ваша фабрика контейнеров всегда может вернуть тот же вид, вы можете поменять местами фреймворки IoC, что угодно.

Пожалуйста, никогда не используйте статические классы, такие как IoC.Container.Resolve или ContainerFactory.GetContainer!

Это делает код более сложным, труднее тестировать, поддерживать, повторно использовать и читать.

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

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

Как продолжение @flipdoubt

Если вы в конечном итоге используете шаблон типа локатора служб, вы можете проверить http://www.codeplex.com/CommonServiceLocator. Он имеет некоторые привязки, доступные для нескольких популярных фреймворков IoC (windsor, structuremap), которые могут быть полезны.

Удачи.

Я бы рекомендовал в этом случае использовать строго типизированные фабрики, как вы упомянули, которые вводятся. Эти фабрики могут обернуть контейнер, но могут разрешить передачу в дополнительном контексте и дополнительную обработку. Например, Create на OrderFactory может принимать контекстные параметры.

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

CommonServiceLocator не предназначен для этой цели, хотя может возникнуть соблазн его использовать. Основная цель CommonServiceLocator - для приложений / фреймворков, которые хотят быть совместимыми с контейнерами IoC. Однако приложения, которые используют, должны оптимально вызывать локатор только один раз, чтобы построить иерархию компонентов и их зависимостей. Его никогда не следует напрямую вызывать снова. Если бы у нас был способ добиться этого, мы бы это сделали. В Prism (http://www.microsoft.com/compositewpf) мы представили IContainerFacade для создания модулей. Это локатор услуг, хотя и низкого уровня. Оглядываясь назад, мы, вероятно, должны были создать ModuleFactory или что-то в этом роде и использовать IContianerFacade, чтобы заполучить его, а затем использовать эти модули разрешения вместо прямого перехода к фасаду. Ретроспективный взгляд - 20/20. Это достаточно низкий уровень, хотя на самом деле это не влияет на вещи.

На CSL мы боролись с наименованием, потому что это могло привести к путанице. В конце концов, мы остановились на CSL, потому что технически интерфейс не позволял вам выполнять DI.

Я бы порекомендовал посмотреть мини-сериал Ника Блюмхардта по этому поводу.

http://blogs.msdn.com/nblumhardt/archive/2008/12/27/container-managed-application-design-prelude-where-does-the-container-belong.aspx

Это действительно общая проблема. Встроенный в Windsor Типизированный заводской объект даст вам преимущества использования фабрики без упомянутых недостатков.