Как Unity (и другие) на самом деле помогают с инъекцией зависимостей - PullRequest
Новая
       9

Как Unity (и другие) на самом деле помогают с инъекцией зависимостей

3 голосов
/ 19 сентября 2011

У меня есть несколько вопросов о контейнерах DI (в частности, Unity) и о том, как они на самом деле помогают в DI.

Мне кажется, я понимаю IoC / DI и уже несколько лет использую DI на основе конструктора.Обычно, когда я использовал DI, это просто включало конструктор в моем классе, скажем, MyClassX, который принимает интерфейс в качестве аргумента, скажем, IDataService, а затем использовал оператор new для создания экземпляра класса реализации IDataService и передачи его в конструктор MyClassX.Таким образом, MyClassX не нужно знать точный тип IDataService, который он использует, отделяя его от определенного типа.Теперь поправьте меня, если я ошибаюсь, но я так понимаю, что DI ... хотя он не обязательно должен быть основан на конструкторе.

Теперь я видел множество примеров Unity в сети, ноМне трудно не только понять все, что он делает (мне кажется, что это фабрика магических объектов), но и то, как он помогает DI, насколько я понимаю.Мне кажется, что Unity больше похож на реализацию Factory (или на Mock Framework?), А не на что-то, связанное с DI.Я думаю, что я действительно что-то упустил, хотя и жду момента "ах-ха".Я много занимался поиском в Google, но примеры не помогают ... Мне нужно теоретическое объяснение.

Может ли кто-нибудь объяснить мне, для чего именно Unity ... широкие аспекты того, что он делает и как онкак я понимаю, относится к DI.

Ответы [ 2 ]

2 голосов
/ 19 сентября 2011

Ваше понимание основных инъекций зависимости является правильным.Внедрение в конструктор является наиболее распространенным шаблоном.

Некоторые другие DI Unity делают:

  1. Управление временем жизни - создание экземпляра может быть одноэлементным, по одному на поток и другоепродвинутые модели.
  2. Обрабатывает графики зависимостей - запрашивает корневой объект, и Unity создает все зависимости его зависимостей.
  3. Включает внедрение метода и свойства - требует атрибут Unityв вашем бизнес-коде (которого я предпочитаю избегать)
  4. шаблон локатора службы - обычно считается анти-шаблоном

1 и2 хороши, когда они вам нужны.Я думаю, что # 3 и # 4 следует по возможности избегать, потому что это добавляет зависимости в вашем коде в ваш контейнер Unity.

Большой взрыв, которого вам не хватает, Аспектно-ориентированное программирование включается Перехват с Unity .Это позволяет реализовать сквозные задачи.Ведение журнала является классическим примером.Если вам нужно больше, начните читать все Обработчики вызовов Enterprise Library для обработки исключений, проверки и т. Д. Или просто начните поиск в Интернете для AOP.

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

0 голосов
/ 19 сентября 2011

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

Допустим, у вас есть класс MyClassX, который зависит от IExampleA, IExampleB. Теперь реализация IExampleA и IExampleB может зависеть от некоторых других классов и так далее. Теперь этот вид графов объектов сложен для обработки вручную, когда дело доходит до его материализации / реализации.

Здесь DI вступает в игру. После регистрации (класс и его зависимые классы) все, что вам нужно сделать, это 

 var myclassX = _container.Resolve<MyClassX>()

И, не поймите меня неправильно, DI может предоставить гораздо больше, чем просто разрешение зависимости. Например, управление объектами LifeStyle и LifeCycle и т. Д.

...