AOP средствами Unity 2.0

В этой статье рассмотрим простой пример реализации AOP (Aspect-Oriented Programming) средствами Unity 2.0. Итак, Unity представляет собой DI/IoC контейнер, с возможностью вносить в него новую функциональность или поведение через стандартные или пользовательские расширения (Extentions).Благодаря этой возможности Unity, мы можем написать свое или воспользоваться уже готовым расширением и реализовать AOP в нашем .NET приложении. Стандартный подход при реализации AOP средствами Unity является использование перехватчика (Microsoft.Practices.Unity.Interception) вызова.
Unity 2.0 предоставляет нам три вида перехвата:

1. InterfaceInterceptor для перехвата методов интерфейса
2. VirtualMethodInterceptor для перехвата виртуальных методов
3. TransparentProxyInterceptor для перехвата методов у объектов типа MarshalByRefObject

Принцип работы перехватчика очень простой. Когда мы делаем resolve-запрос к Unity контейнеру мы получаем динамически сгенерированный прокси-объект, делегирующий искомый тип. Функционально прокси устроен следующим образом: ПЕРЕД тем и ПОСЛЕ того, как прокси передаст вызов на искомый объект, он выполнит код перехватчика (на практике обычно это pipe из нескольких обработчиков, реализующих интерфейс ICallHandler), передав ему все необходимые параметры вызова. Этого вполне достаточно для реализации AOP поведения.

IoC/DI в WCF на примере Unity 2.0

В этой статье я продемонстрирую процесс внедрения IoC/DI контейнера (на примере Unity 2.0) в WCF сервис. В примере я выбрал Unity 2.0, но на самом деле это не существенно, и по желанию можно легко адаптировать код под другой IoC/DI контейнер. Для тех кто не знаком еще с данным контейнером, рекомендую глянуть вводную статью. Существуют несколько путей внедрения IoC/DI контейнера в WCF сервис, рассмотрим один из них*.
Итак, предже чем приступить к реализации наметим основные шаги:

1. Для начала создадим простой WCF сервис
2. Реализуем свой IInstanceProvider
3. Далее опишем собственную реализацию IServiceBehavior
4. Определим BehaviorExtensionElement
5. И закончим, добавив необходимые настройки в web.config

*На самом деле это не единственный способ внедрения контейнера, существуют варианты с использованием ServiceHostBase и ServiceHostFactoryBase

Hello, Unity 2.0

Рассматривая ранее принцип инверсии зависимости, мы остановились на том, что нам нужен некий IoC/DI фреймворк, который помог бы нам избавиться от рутинной работы. Как я уже говорил, существуем множество различных IoC/DI фреймворков:

1. Microsoft Unity
2. Ninject
3. Autofac
4. StructureMap
5. Castle
6. Spring.Net

В этой статье мы познакомимся с open-source IoC/DI контейнером от Microsoft Unity 2.0 под .NET 4.0. Работать с данным фреймворком очень легко, и я продемонстрирую это Вам на простом примере, проделав простых 5 шагов:

1. Создадим новый проект и добавим в него основные сущности. Смотри предыдущую статью.
2. Скачаем необходимые библиотеки.
3. Добавим references на них в проекте.
4. Настроим IoC-контейнер через конфигурационный XML-файл.
5. С помощью IoC-контейнера получим экземпляр объекта нашего класса.

Принцип инверсии зависимости

Что такое зависимость? Задавались ли Вы вопросом, как много зависимостей присутствует в Вашем проекте? Для начала проясним ситуацию и определим понятие зависимость. Представьте ситуацию: есть 2 класса, один(X) из которых использует другой(Y), например делает вызовы методов - это и есть зависимость одного от другого (X от Y).