Io C-контейнеры и прочие прелести связанные с зависимостями

Io. C-контейнеры и прочие прелести, связанные с зависимостями

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

Немного скучной терминологии Сервис (Service) – абстрактный контракт, описывающий некоторую функциональную единицу. Сложно. Простой пример: interface IWoman { void Cook(); Baby Create. Baby(); }

Немного скучной терминологии Компонент – некоторая реальная реализация сервиса. public Woman : IWoman { public Woman(IKitchen kitchen) { … } public void Cook() { … } public Baby Create. Baby() { Thread. Sleep(Time. Span. From. Days(9 * 30)); return new Baby(); } }

ООП – большое количество взаимосвязанных объектов, реализующих различные классы. Связи между ними могут быть абсолютно разные: кто-то кого-то порождает, кто-то использует возможности других объектов… (есть умные слова из UML: агрегация, ассоциация, …) Классы, в свою очередь, реализуют определенные интерфейсы (в идеальном случае)

О зависимостях Принцип инверсии управления: Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Все должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Промежуточный вывод Интерфейсы. Больше интерфейсов. Нет, ты не понял, ЕЩЕ БОЛЬШЕ ИНТЕРФЕЙСОВ. К чему это приведет?

Промежуточный вывод Много сервисов. ОЧЕНЬ. МНОГО. СЕРВИСОВ. Много реализаций сервисов, которые могут использовать другие сервисы => получаем компоненты, которые зависят от других сервисов.

А пользоваться-то этим как? Вариант первый: Service Locator. Вообще говоря паттерн, который инкапсулирует процесс предоставления какого-то сервиса. Можно рассматривать как Dictionary>, то есть некоторый реестр, который связывает сервис и его существующие реализации. Service Locator должен быть одним на приложение (например, реализованный статичным классом). Должен уметь выдавать реализацию по типу сервиса.

Еще про Service Locator Процесс регистрации сервисов тоже не очень веселый, приходится самому создавать инстансы. Приходится все зависимости разрешать исключительно руками => можно где-то потерять разрешение зависимости и выстрелить себе в ногу в рантайме (то есть словить Null. Reference. Exception).

Да придет спаситель Программисты – народ ленивый. Поэтому были разработаны замечательные библиотекифреймворки – Io. C-контейнеры (Io. C – inversion of control). Io. C-контейнер может: Контролировать лайф-тайм компонентов (начиная с момента создания и заканчивая моментом уничтожения); Разрешать цепочки зависимостей; Следить за регистрациями зависимостей. Exception мы словим, но еще в начале работы приложения; Регистрировать зависимости ПАЧКАМИ.

Правила работы с Io. C-контейнером 1. Регистрируем все зависимости; 2. Собираем контейнер; 3. Резолвим ОДИН компонент-корень; 4. В конце работы приложения убиваем контейнер.

Как можно объявлять о зависимостях Через конструктор (лично я считаю данный подход наиболее правильным); Через метод-сеттер; Через атрибуты.

Немного о жизненных циклах объектов Transient Singleton Per web request …

О реальных библиотеках, которые используем мы Castle. Windsor Autofac Так как обе библиотеки являются Io. C-контейнерами, то принцип использования очень похож. Но у каждой есть свои плюшки и свои особенности.

Как мы пользуемся Windsor’ом и его плюшки Покажу практически

Как мы пользуемся Autofac’ом (и зачем) Покажу практически