Резюме
Данная глава представляет собой дегустационное меню StructureMap и его возможностей. Мы соотносим принципы и паттерны остальной части книги с API контейнера StructureMap. StructureMap – это старейший из доступных в .NET DI-контейнеров, но этот факт ничего не говорит ни о его возрасте, ни о доминирующем использовании вложенных замыканий (Nested Closures), ни о его конфигурационном API, которое обладает свойством типовой безопасности, ни о возможности поиска типов в нем на основании соглашений.
Использование паттерна Nested Closure, возможно, является одной из самых отличительных особенностей StructureMap. Для его использования необходимо хорошо разбираться в делегатах и блоках кода.
Начать работать со StructureMap довольно легко. Он поддерживает автоматическую интеграцию и автоматически определяет, каким образом создавать конкретные типы, даже если они не были явным образом сконфигурированы. Это означает, что вы можете сконцентрироваться на преобразовании абстракций в конкретные типы, и, когда вы закончите это преобразование, вы сможете разрешать диаграммы объектов. API, используемое для поиска типов, даже дает вам возможность сконфигурировать множество сервисов посредством всего нескольких строк кода, используя при этом для конфигурирования подход, основанный на соглашениях.
Несмотря на то, что нам не нужно конфигурировать конкретные сервисы, мы можем захотеть сделать это в тех ситуациях, когда нам нужно изменить стиль существования. По умолчанию используется стиль существования Per Graph, поэтому всякий раз, когда у нас имеются потоко-безопасные сервисы, мы можем потенциально увеличить эффективность путем конфигурирования их в виде Singleton'ов. Для этого нужен определенный шаг, несмотря на то, что можно было бы выразить это во время поиска типа посредством использования пользовательского соглашения о регистрации.
Не гарантируется, что экземпляры будут отслеживаться контейнером, поэтому StructureMap не предлагает никакого API для высвобождения конкретной диаграммы объектов. Это эффективно предотвращает утечки памяти для обычных классов, но, с другой стороны, почти гарантирует утечки памяти для устраняемых зависимостей. Поэтому важно реализовывать все зависимости таким образом, чтобы они самостоятельно управляли всеми внутренними использованиями устраняемых типов.
StructureMap свободно обрабатывает последовательности зависимостей. Когда класс зависит от последовательности экземпляров одного и того же типа, StructureMap будет автоматически интегрировать экземпляр со всеми экземплярами того типа, который имеет зависимость. Поведение StructureMap интуитивно понятно, поэтому нам нужно всего лишь явно выполнить определенное действие в тех ситуациях, когда нам требуется отобрать только некоторое подмножество экземпляров из всех доступных экземпляров.
Несмотря на то, что мы можем явным образом сконфигурировать Decorator'ы, StructureMap не имеет никаких соглашений по интеграции Decorator'ов и не обладает возможностями динамического перехвата. Существуют Seam'ы, которые могут использоваться для того, чтобы интегрировать в StructureMap динамическое прокси API, если нам нужно интегрировать Decorator'ы.
Поскольку StructureMap столь глубоко полагается на вложенные замыкания, неудивительно, что многие методы конфигурации обладают перегрузками, дающими нам возможность использовать блок кода, который будет вызываться при создании экземпляров. Несмотря на то, что эти перегрузки не являются необходимыми в тех ситуациях, когда регистрируемые нами классы используют Constructor Injection, мы можем использовать их, если один или более одного из наших классов должны создаваться особым образом.
StructureMap – исчерпывающий DI-контейнер, который предлагает широкий набор продвинутых возможностей. Он имеет отличное поведение по умолчанию и может с легкостью использоваться, особенно в тех случаях, когда дело касается автоматической интеграции конкретных типов или последовательностей. С другой стороны, он не обладает возможностями динамического перехвата и не может уничтожать устраняемые зависимости. Эти очевидные недостатки являются, главным образом, результатом философии проектирования. Если мы никогда не будем реализовывать устраняемые сервисы и вместо динамического перехвата решим использовать явные Decorator'ы, то в этом случае StructureMap является отличным вариантом, поскольку он использует эти ограничения для того, чтобы упростить для пользователей все остальное.
