Резюме

Обзор Castle Windsor, предоставленный в данной главе, только обрисовывает то, что возможно выполнить с помощью одного из самых развитых и исчерпывающих, доступных DI-контейнеров. Поскольку Seam'ы находятся повсюду, мы можем настроить контейнер для наших собственных нужд, и при этом станут доступными многие дополнительные возможности.

В данной главе мы сконцентрировалась на наиболее универсальной части API Windsor. Представленный в ней материал охватывает основное применение контейнера, а также советы по более продвинутым составляющим его API. Это все, что вам нужно знать, если ваша база кода руководствуется DI паттернами и соглашениями. Вооружившись данным знанием, вы должны уметь подключать с помощью Castle Windsor целые приложения.

Даже будучи пустым DI-контейнером, Castle Windsor является довольно значительным. Он поддерживает практически любую возможность, которую мы могли бы запросить. Являясь одним из самых старейших .NET DI-контейнеров, он значительно выигрывает благодаря длительным годам своего развития. Однако это не демонстрирует его возраст; напротив, он поддерживает множество новых идей и современных конструкций языка. Все же, возможно, самый значительный недостаток Castle Windsor заключается в том, что огромный набор возможностей реализуется за счет утраты некоторого неоднородного API. Несмотря на то, что начать работать с классом WindsorContainer довольно легко, более продвинутые сценарии реализовывать будет сложно до тех пор, пока вы точно не овладеете всем API. К счастью, поскольку форум поддержки Castle Windsor активен, и опытные разработчики выполняют его мониторинг, если у вас появляется вопрос, вы, скорее всего, быстро получите ответ на него.

Несмотря на то, что продвинутое API может казаться устрашающим, начать работать с Castle Windsor намного легче, чем с любым другим DI-контейнером: создайте экземпляр WindsorContainer, сконфигурируйте его и разрешайте с помощью него компоненты.

Существует несколько способов конфигурирования контейнера: возможно и использование кода в качестве конфигурации (code as configuration), и XML, и конфигурация на основании соглашений; мы даже можем сочетать и сопоставлять все эти три способа, чтобы достичь оптимального решения.

В Castle Windsor доступен широкий набор стилей существования, включая Singleton, Transient и Web Request Context. Если не подходят встроенные стили существования, вы можете реализовать пользовательские стили существования – но такое довольно редко случается.

Кажется, что поддержка составных компонентов одной и той же абстракции является одной из слабых сторон Castle Windsor. Он, кажется, лучше понимает массивы, чем другие типы последовательностей или списков, но мы можем справиться с этим недостатком довольно легко. Точный способ решения данной проблемы зависит от того, хотим мы разрешить все компоненты или только подмножество компонентов одного и того же сервиса.

Несмотря на то, что нам следует полагаться на автоматическую интеграцию, метод ServiceOverrides дает нам возможность явным образом сконфигурировать то, как зависимости присваиваются компонентам.

Иногда компоненты не используют Constructor Injection, а вместо него могут использовать Property Injection или требовать использования отдельных классов фабрики. Такие сценарии также поддерживаются посредством различных методов.

Поскольку Castle Windsor является одним из самых универсальных среди доступных DI-контейнеров, нет причины не использовать его, но он не исключает альтернатив, которые столь же хороши. В следующей главе мы рассмотрим другой развитый и продвинутый DI-контейнер: StructureMap.

или RSS канал: Что новенького на smarly.net