Первые шаги с Unity: DI/IoC & AOP

Введение

 

Если Вы когда-нибудь слышали такие слова, как IoC, DI, AoP, но не имеете четкого понимания этих терминов, надеюсь, эта статья поможет в них разораться на примере работы с Microsoft Unity контейнером.

Итак, приступим к теории:

Inversion of Control (IoC) и Dependency Injection (DI)

За определением IoC обратимся к википедии:

Обращение контроля* (Inversion of Control, IoC) — важный принцип объектно-ориентированного программирования, который используется для уменьшения связности в компьютерных программах.

IoC также известен как Dependency Injection Principle. Приём Dependency Injection используется почти во всех framework’ах. Он применяется программистами использующими такие объектно-ориентированные языки программирования как Smalltalk, C++, Java или языки платформы .NET.

*Сразу же хотелось оговориться, что мне больше по душе не употреблять для IoC русскоязычного перевода, но всё же если меня заставят это сделать, что я употреблю его, как "инверсия управления"

За определением DI так же обратимся к википедии:

Внедрение зависимости (англ. Dependency injection) обозначает процесс предоставления внешней зависимости программному компоненту и является специфичной формой «обращения контроля (англ. Inversion of control)», где изменение порядка связи является путём получения необходимой зависимости.

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

Для разрешения проблем зависимостей одного объекта от другого обычно на объект, имеющий зависимость возлагают ответственность за создание/получение необходимого ему объекта (Хотелось бы к слову обратить Ваше внимание на такие шаблоны, как Factory, Registry).

Примеров реализации с приведением псевдо-кода IoC и DI великое множество, в связи с этим не очень хочется, чтобы статья разрасталась из-за них, а лучшего понимания, чем при практическом использовании, я врядли смогу вам предоставить.

Думаю, тут будет полезно привести список .NET DI/IoC контейнеров:

Aspect-oriented programming (AoP)

Признаю, я дотошный почитатель википедии:

Аспектно-ориентированное программирование (АОП) — парадигма программирования, основанная на идее разделения функциональности, особенно сквозной функциональности, для улучшения разбиения программы на модули.

Хотелось бы добавить, что Аспектно-ориентированное программирование (АОП) так же призвано прийти на помощь ООП для того, чтобы сократить количество написанного в приложениях кода.

Чаще всего использование АОП сводится к осуществлению повседневных рутинных задач, таких как логгирование,  кэширование, валидация, так же управление доступом. Можно возразить и сказать, что можно решить эту проблему можно при помощи обволакивания ваших бизнес-объектов шаблона Decorator (рус.), но дело в том, что при этом возникает необходимость изменения кода потребителя, а АОП позволяет сделать это легко и непринужденно.

Известные framewоrk’и:

О Microsoft Enterprise Library

Как известно, в октябре 2008 года Microsoft обновили версию Enterprise Library до 4.1, соотвественно одну из её составляющих Unity Application Block до версии 1.2. Разработкой Microsoft Enterprise Library занимается группа patterns & practices. Microsoft Enterprise Library представляет собой набор функциональных блоков, призваных помочь разработчикам в выполнении обычных рутинных задач. Функциональные блоки — что-то типа руководства, предоставляемый в их составе исходный код можно использовать "как есть", расширять или изменять разработчикам в соответствии с их нуждами. Microsoft Enterprise Library состоит из следующих блоков:

  • Caching Application Block. Разработчики могут использовать этот блок для реализации кэширования в своих приложениях. Поддерживает так же подключаемые кэш провайдеры .
  • Cryptography Application Block. Разработчики могут использовать этот блок для реализации хеширования и симметричного шифрования в приложениях.
  • Data Access Application Block. Разработчики могут использовать этот блок для реализации стандартных действий с базой данных в своих приложениях.
  • Exception Handling Application Block. Разработчики и редакторы правил могут использовать этот блок для реализации последовательной стратегии обработки исключений, которые происходят на всех архитектурных слоях корпоративных приложений.
  • Logging Application Block. Разработчики могут использовать этот блок для реализации стандартных функций логирования.
  • Policy Injection Application Block. Разработчики могут использовать этот блок для реализации политик перехвата для того, чтобы насытить приложение такими возможностями, как логирование, кеширование, обработка исключений и валидация на уровне всего приложения.
  • Security Application Block. Разработчики могут использовать этот блок для реализации механизма авторизации и безопасности приложений.
  • Unity Application Block. Разработчики могут использовать этот блок, как легковесный, расширяемый dependency injection контейнер с поддержкой внесения зависимостей в конструктор, свойство и вызов методов, таким же образом, как и реализация перехвата, через расширения.
  • Validation Application Block. Разработчики могут использовать этот блок для реализации правил валидации для бизнес-объетов, используемых в приложении.

О Unity Application Block

легковесный, расширяемый dependency injection контейнер с поддержкой внесения зависимостей в конструктор, свойство и вызов методов, таким же образом, как и реализация перехвата, через расширения. Вы можете использовать его вместе с Enterprise Library (EntLib) для генерации объектов, как ваших собсвенных, так и Enterprise Library. Однако, Unity Application Block отличается от остальных функциональных блоков EntLib в нескольких ключевых моментах:

  • Вы можете использовать Unity Application Block как автономный механизм внесения зависимостей, не нуждаясь в установленной EntLib.
  • Unity Application Block может быть сконфигурирован как с помощью спецализированных файлов конфигурации, так и в run-time режиме с помощью вашего кода.
  • Unity Application Block независим от ядра EntLib, ровно как от системы конфигурации EntLib. Он содержит свой собственный механизм для конфигурирования, хотя, при желании вы можете использовать механизм конфигурации EntLib.

Долгожданный In Action

Можно увидеть по адресу http://butaji.habrahabr.ru/blog/50845/

Материалы

  • Написание это статьи было инициировано просмотром небольшого скринкаста от David Hayden. Примеры кода с небольшими поправками позаимствованы из него.
  • При написании статьи, в основном, я руководствовался базовыми знаниями, почерпнутыми когда-то из замечательной книги “Applying Domain-Driven Design and Patterns” by Jimmy Nilsson.
  • Так же замечательной кладезью знаний Википедия.

В завершение

Надеюсь в данной статье дано хорошее начало для ваших изысканий в области качественного кода.

P.S. Это мой первый пост на хабре, поэтому немного о себе: горизонт моих интересов очень широк, в технической его составляющей это .NET-разработка (ASP.NET, Sharepoint, WWF, Silverlight), методики разработки (Agile, Scrum, XP), техники разработки (TDD, DDD, MDA, AOP).

Advertisements

One Comment on “Первые шаги с Unity: DI/IoC & AOP”

  1. smp:

    почему сразу ссылки на IoC framework-и а ручками это сделать слабо? 😉


Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s