в чем смысл механизма внедрения зависимостей?
Я уверен, что я несколько потерян в этой области ... Я понимаю, что внедрение зависимостей означает инициализацию чего-то, что требуется классу, например, так. Если моему контроллеру понадобится сервис, и я хочу иметь возможность его протестировать, я должен определить для него два метода конструктора ... итак, мой вопрос ... почему люди используют Frameworks для достижения этой цели ?? Im lost
public class CompaniesController : Controller
{
private ICompaniesService _service;
public CompaniesController()
{
_service = new CompaniesService();
}
public CompaniesController(ICompaniesService service)
{
_service = service;
}
6 ответов
Люди не используют Dependency Injection Framework для генерации кода, который вы привели в своем примере. Это все еще работа разработчика.
Dependency Injection Framework используется, когда кто-то вызывает конструктор. Framework инжектирует конкретную реализацию ICompaniesService вместо того, чтобы разработчик явно вызывал конструктор.
Хотя это специфический продукт, на nInject Homepage есть несколько действительно хороших примеров.
Я думаю, что ваше понимание верно лишь отчасти. Dependency Injection - это "внедрение" зависимость компонента в него. Это более специфическая форма инверсии управления. Во время этого процесса некоторые зависимости могут быть инициализированы до инъекции.
При использовании DI бремя поиска зависимости лежит не на компоненте. (как в шаблоне ServiceLoacator), а на контейнер, в котором работает компонент. запущен. Этот паттерн имеет следующие преимущества:
- Код поиска зависимостей может быть исключен из компонента.
- Некоторые фреймворки обеспечивают автоматическое подключение, инжектирование, избавляя вас от необходимости вручную создавать иерархию компонентов. иерархии компонентов (ответ на один из ваших вопросов)
- Позволяет вам обмениваться реализациями зависимостей. (без использования фабрик)
- Тестирование (замена зависимостей имитационными реализациями)
В вашем примере кода зависимость может быть инжектирована DI-контейнером во время выполнения через второй конструктор. Возможны и другие формы инъекций (в зависимости от DI-контейнера). например, инъекция поля, инъекция сеттера и т.д. инъекция поля, инъекция сеттера и т. д.
Есть хорошая статья Мартина Фаулера, который придумал термин DI
Люди используют фреймворки внедрения зависимостей, потому что в противном случае вам придется написать тонну скучных, повторяющихся фабричных классов (то есть, если используется внедрение зависимостей).
Это можно сделать, это очень и очень раздражает.
Из Википедии :
Без концепции зависимости инъекции, потребитель, которому нужен конкретный сервис «ICompaniesService» для того, чтобы выполнить определенную задачу было бы отвечает за обработку жизненный цикл (создание, открытие и закрытие потоков, удаление и т. д.) эта услуга. Используя концепцию внедрение зависимости, однако жизненный цикл услуги обрабатывается зависимость поставщик / фреймворк (обычно контейнер), а не потребитель. Таким образом, потребителю понадобится только ссылка на реализацию сервис "ICompaniesService" , который необходим для выполнить необходимую задачу.
Прочтите и это:
Основная причина состоит в том, чтобы лучше поддерживать модульное тестирование и имитировать объекты для создания контролируемых тестов.
Не определяя реализацию внутри класса, вы можете «внедрить» реализацию во время выполнения. (В вашем примере интерфейс ICompaniesService).
Во время выполнения, используя инверсию контейнера внедрения управления / зависимости, такого как StructureMap, Unity или Castle Windsor, вы можете сказать: «Эй, в любое время, когда кому-то понадобится экземпляр ICompaniesService, дайте ему новый объект CompaniesService».
Для модульного тестирования этого класса вы можете смоделировать нашу ICompaniesService и передать ее конструктору. Это позволяет вам настраивать контролируемые методы для фиктивного объекта. Если бы вы не могли этого сделать, ваши модульные тесты для CompaniesController были бы ограничены использованием только одной реализации службы вашей компании, которая могла бы попасть в действующую базу данных и т. Д., Что сделало бы ваши модульные тесты медленными и непоследовательными.
Вам не обязательно иметь структуру DI, но в какой-то момент в вашей кодовой базе нужно будет создать конкретную реализацию и внедрить ее в ваши конструкторы / свойства. Это может стать очень запутанным, если у вас нет инфраструктуры DI, я рекомендую посмотреть Castle Windsor, хотя, как уже упоминалось, есть другие, которые будут выполнять ту же функцию. Или, если бы вы могли роль своего собственного ....:)