Inversion of Control и Dependecny Injection в .net по-прежнему нетривиальный квест и тренировка архитектурного мышления, несмотря на обилие публикаций по теме. Почему IoC контейнер это фреймворк и причём здесь кулинария? Как построить дизайн системы вокруг IoC контейнера и не прострелить себе ногу? Почему ServiceLocator это плохо и как без него обойтись? Как мы отвечали на эти вопросы и наступали на грабли внедрения зависимостей в масштабе приложения.

1. Dependency Injection.
Как сказать всё, не говоря
ничего
Кожевников Дмитрий
.NET

2. Докладывает
• Кожевников Дмитрий
• .NET разработчик
• > 3 года enterprise разработки
• Информатизация ЖКХ
• Интеграция банковских систем
• Организация it-движухи
• Email d.o.kozhevnikov@gmail.com
2

3. Enterprise разработка
• Поколения разработчиков
• Много legacy code
• Много технических долгов
• Тяжёлая поддержка
3

4. Enterprise разработка
4

5. Сложным приложениям – гибкий дизайн
5

6. Разделение ответственности
6

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

8. Инверсия управления
Inversion of Control
8
• Детали зависят от абстракций
• Использование абстрактной инфраструктуры
• Инвертирование зависимостей

9. Зависимость
Dependency
• Предоставление инфраструктуры
• Отделение интерфейса от реализации
9

10. Внедрение зависимостей
Dependency Injection
• Поставка зависимостей
• Создание и конфигурация инфраструктуры
10

11. Как решаются проблемы
• Слабая связность
• Понятная сборка композиции
• Абстрактный код компилируется
• Ярко выраженные запахи кода
11

12. Внедрение через конструктор
Constructor Injection
12

13. Уровень абстракции
13

14. Макароны в конструкторах
14

15. Раминь!
15

16. Проблемы внедрения через конструктор
• Вызовы конструкторов становятся слишком большими
• Неясно, когда остановиться и кому отдать ответственность за DI
Кто поможет?
16

17. IoC-контейнеры
17

18. Настройка контейнера
18

19. Resolve<T>()
19

20. ServiceLocator
20

21. Проблемы и ServiceLocator
• Вызовы конструкторов становятся слишком большими
• Неясно, когда остановиться и кому отдать ответственность за DI
21

22. ServiceLocator + Singleton
22

23. ServiceLocator это вундервафля
23

24. Ересь ServiceLocator
• Императивный
• Всемогущий
• Повышает связность
• Машина костылей
24

25. Пример #1
25

26. Пример #2
26

27. Инверсия управления именем Императора
• IoC как framework
• CompositionRoot
• Register-Resolve-Release
27

28. Composition Root
28

29. Register-Resolve-Release
29

30. Инверсия управления как framework
• Один контейнер
• Единая композиция приложения
• Контейнер – глобальный сборщик
• Инверсия управления на полную
30

31. Почему IoC framework?
• Весь набор плюшек IoC
• Декларативная инфраструктура
• Интеграционное тестирование по уровням
• Отсутствие битых стёкол
• Размышления над дизайном
31

32. Итог: сложность не нужна!
32

33. Причём здесь кулинария?
33

34. Ссылки
• Кулинария http://www.ozon.ru/context/detail/id/22104901/
• Модули
http://code.google.com/p/autofac/wiki/StructuringWithModules
• CompositionRoot
http://blog.ploeh.dk/2011/07/28/CompositionRoot/
• Register-Resolve-Release
http://blog.ploeh.dk/2010/09/29/TheRegisterResolveReleasepattern/
34

35. Спасибо за внимание!
35

36. Вообще без new?
• string, int, double
• Domain Entities
• DTO
• POCO
36

37. Resolve после CompositionRoot? Factory!
37

38. Несколько реализаций? #1
38

39. Несколько реализаций? #2
39

40. Несколько реализаций? #3
40

41. External
Infrastructure
Core
UI & API
IoС Container
41

42. Правда всё!
42