Формы инверсии зависимостей

Существует две формы инверсии зависимостей: активная и пассивная. Различие между ними состоит в том, как объект узнает о своих зависимостях во время выполнения.

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

Активная форма, в отличие от пассивной, предполагает, что зависящий объект будет сам получать свои зависимости при помощи вспомогательных объектов.

Каждая из форм инверсии зависимостей имеет подтипы, которые характеризуют детали связывания объектов между собой.

Пассивная инверсия зависимостей (Dependency Injection):

• внедрение через конструктор: для ассоциирования объекта с конкретными реализациями абстракций используется конструктор. При использовании этого типа инверсии зависимостей необходимые объекты передаются в конструктор в качестве аргументов.

• внедрение через устанавливаемое свойство: требуется определение отдельного свойства, имеющего set-метод, для каждого из инъецируемых объектов. От предыдущего типа инъекции она отличается местом инъекции. Следует отметить, что внедрение через конструктор и внедрение через устанавливаемое свойство не исключают друг друга.

• внедрение через интерфейс: задаются интерфейсы, которые определяют методы для связывания, один интерфейс на каждую зависимость. Зависимый объект должен реализовывать все эти интерфейсы. Определяется также единый интерфейс для всех сервисов. Каждый сервис реализует этот интерфейс таким образом, чтобы внедрить себя в зависящий объект. Таким образом, сервисы сами внедряют себя в зависимый объект посредством установленного интерфейса.

• внедрение через поле: в .NET и Java существует возможность получить доступ к private/protected полям объекта. Эта техника может быть использована для внедрения сервисов в зависящий объект напрямую, без использования set-методов и конструкторов.

Активная инверсия зависимостей (Dependency Lookup):

• pull-подход: предполагается наличие в системе общедоступного объекта, который знает обо всех используемых сервисах. В качестве такого объекта может выступать объект, реализующий паттерн Service Locator. Локатор реализует паттерн синглетона, благодаря чему доступ к нему можно получить из любого места приложения.

• push-подход: данная методика отличается от pull-подхода тем, как объект узнает об объекте-локаторе. При использовании pull-подхода класс сам получал локатор посредством класса-синглетона. Push-подход характеризуется тем, что объект-локатор (или как его иногда называют контекст) передается в класс извне (обычно через конструктор).

IoC контейнер

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

Одной из реализаций IoC контейнера является MEF. Это очень мощный проект, который затрагивает очень много аспектов конструирования ПО. Одним из таких аспектов является конструирование объектов на основании его связей. Причем связи между объектами могут задаваться в виде атрибутов и анализироваться в процессе выполнения приложения.

MEF

Библиотека MEF появилась относительно недавно, но быстро завоевала популярность у .NET разработчиков за простоту использования и эффективность. Она позволяет строить модульные приложения с минимальным уровнем связности частей (parts) приложения. Эта библиотека включает в себя не только Dependency Injection контейнер, но большой объём инфраструктуры: множество механизмов поиска элементов композиции в сборках, удалённых XAP файлах, механизм пометки элементов композиции с помощью .Net атрибутов и т.д. Также существует версия MEF для Silverlight, которая имеет незначительные отличия от настольной версии.

IoC контейнер в MEF инкапсулируется классом CompositionContainer. Он содержит каталог типов, доступных для инъектирования. Наиболее удобным каталогом является DirectoryCatalog, включающий в себя типы из всех сборок, найденных в папке с приложением:

1: CompositionContainer container =

2: new CompositionContainer(new DirectoryCatalog("."));

Для удовлетворения зависимостей определенного класса используется метод ComposeParts:

1: container.ComposeParts(this);

Стоит иметь в виду, что как и другие IoC контейнеры, перед передачей компоненты в качестве импорта MEF удовлетворяет все её зависимости.

Компоненты в MEF не зависят друг от друга напрямую, вместо этого они зависят от контракта, который указывается строковым идентификатором. Каждый компонент объявляет контракты, которые он реализует, а каждая зависимость указывает необходимый ей контракт.

Реализация какого-либо контракта в терминологии MEF называется экспортом. Экспорты задаются при помощи атрибута [System.ComponentModel.Composition.ExportAttribute]. Данным атрибутом помечается класс сервиса, реализующего контракт. В качестве аргумента в конструктор атрибута передается имя реализуемого контракта. Следующий пример определяет контракт ILogger и объект Logger, его реализующий:

1: public interface ILogger

2: {

3: void Log(string message);

4: }

5:

6: [Export(typeof(ILogger))]

7: public class Logger : ILogger

8: {

9: public void Log(string message)

10: {

11: Console.WriteLine(message);

12: }

13: }

Чтобы различать несколько реализаций одного контракта, в экспорте возможно указать его имя:

1: [Export("GUI", typeof(ILogger))]

2: public class Logger : ILogger

3: {

4: public void Log(string message)

5: {

6: MessageBox.Show(message);

7: }

8: }

В таком случае возможно как получить все реализации контракта ILogger, так и найти конкретную спецификацию, работающую с графическим интерфейсом, по ключевому слову GUI.

По умолчанию MEF работает по принципу пассивной инверсии зависимостей. Зависимости от компонент в терминологии MEF называются импортами. Импорты с внедрением через устанавливаемое свойство или поле задаются при помощи атрибута [System.ComponentModel.Composition.ImportAttribute].

1: public class Processor

2: {

3: [Import]

4: public ILogger Logger { private get; set; }

5:

6: public void Process()

7: {

8: Logger.Log("Hello world");

9: }

10: }

При внедрении через конструктор, этот конструктор помечается атрибутом [System.ComponentModel.Composition.ImportingConstructorAttribute].

1: public class Processor

2: {

3: [ImportingConstructor]

4: public Processor(ILogger logger)

5: {

6: _logger = logger;

7: }

8:

9: // Private fields

10: private ILogger _logger;

11:

12: public void Process()

13: {

14: _logger.Log("Hello world");

15: }

16: }

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

1: public class Processor

2: {

3: [Import("GUI")]

4: public ILogger Logger { private get; set; }

5:

6: public void Process()

7: {

8: Logger.Log("Hello world");

9: }

10: }

Помимо пассивной инверсии зависимостей при помощи MEF возможно реализовать активную инверсию зависимостей с использованием библиотеки CommonServiceLocator. Данная библиотека содержит обобщенный интерфейс для разрешения зависимостей, абстрагированный от конкретного IoC контейнера:

1: var locator = new MefServiceLocator(CompositionContainer);

2: ServiceLocator.SetLocatorProvider(() => locator);

MVVM и IoC

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

Здесь необходимо принять архитектурное решение, так как при разрешении зависимостей необходимо иметь в виду порядок создания объектов:

• Конструировать модель представления первой. В таком случае представление будет иметь зависимость (прямую, или на уровне конвенции наименований) от модели представления.

• Конструировать представление первым. Тогда модель представления будет требовать в качестве зависимости представление.

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