Где именно разница между IoC и DI
Возможный дубликат:
Инверсия контроля <Инъекция зависимости
Я всегда читаю IoC(Inversion of Control) и DI(Dependency Injection) в одном и том же контексте. В чем разница между IoC и DI? Чем IoC отличается от DI?
2 ответа
В обычном использовании термины стали несколько синонимами. Первоначальная идея IoC - Inversion of Control - была очень тесно связана с "Голливудским принципом:" Не звоните нам, мы позвоним вам ".
В традиционных приложениях разработчики пишут бизнес-код и программный код. Затем бизнес-код вызывает код структуры для выполнения задач. В модели IoC вы "инвертируете" эту модель и создаете структуру, которая принимает бизнес-модули и вызывает их для выполнения задач. Этот принцип демонстрируется в нескольких средах разработки, включая старую фабрику программного обеспечения Smart Client и более новую Prism (или составные приложения для WPF / Silverlight). В этих моделях модули пользовательского интерфейса регистрируются в контейнере IoC и загружаются по мере необходимости в зависимости от конфигурации и действий пользователя. Несмотря на свою мощь, эти модели, как правило, имеют очень крутую кривую обучения.
Внедрение зависимостей - это техника (на самом деле сложно назвать это шаблоном) удаления внутренних зависимостей из реализаций, позволяющая зависимым объектам вводиться в класс / метод внешним вызывающим объектом. Фреймворки IoC используют внедрение зависимостей для предоставления пользовательских модулей и другого зависимого кода в подпрограммы фреймворка, которые "склеивают все вместе". Внедрение зависимостей активно используется платформами IoC, потому что это механизм, который позволяет им "Позвонить вам".
Контейнеры IoC, такие как Castle Windsor и Structure Map, помогают с внедрением зависимостей, обеспечивая автоматическое создание экземпляров и управление жизненным циклом зарегистрированных вами классов, включая автоматическое создание экземпляров и внедрение параметров, требуемых зарегистрированными классами. Все это упрощает использование внедрения зависимостей, но не является обязательным.
Внедрение зависимостей - это механизм гибкости, который максимизирует зависимость от интерфейсов, минимизируя зависимость от конкретной реализации. Следовательно, системы, использующие внедрение зависимостей, могут поддерживать "подключаемые" классы реализации, которые могут использоваться в зависимости от обстоятельств. Очень большое преимущество этой "подключаемости" заключается в том, что она значительно упрощает создание модульных тестов. Вы можете смоделировать объект в нужном интерфейсе, а затем внедрить его в свой тестовый объект.
Итак, IoC - действительно более широкий принцип, а DI - фундаментальный метод внутри. Системы IoC (принцип Голливуда) имеют тенденцию быть довольно сложными, могут быть трудными для понимания и, следовательно, иметь крутые кривые обучения. DI, с другой стороны, является хорошей практикой для обычных разработчиков. Я склонен предпочесть понятное и ясное, а не классное, но сложное.
IoC - это возможность варьировать выполнение контракта.
DI - это способность предоставлять реализацию.