Ответ 1

В обычном использовании термины стали несколько синонимичными. Первоначальная идея IoC - Inversion of Control - была очень связана с "Голливудским принципом:" Не позвоните нам, мы позвоним вам ".

В традиционных приложениях разработчики будут писать бизнес-код и код структуры. Затем бизнес-код вызовет код рамки для выполнения задач. Под моделью IoC вы "инвертируете" эту модель и создаете фреймворк, который принимает бизнес-модули и называет их для выполнения задач. Этот принцип представлен в нескольких средах разработки, включая старое программное обеспечение Smart Client Software Factory и более новые приложения Prism (или Composite Applications для WPF/Silverlight). В этих моделях UI-модули регистрируются в контейнере IoC и загружаются по мере необходимости на основе настроек и действий пользователя. Несмотря на свою мощь, эти модели также имеют очень крутую кривую обучения.

Инъекция зависимостей - это метод (трудно назвать его образцом, действительно) для удаления внутренних зависимостей от реализаций, позволяя зависимым объектам вводиться в класс/метод внешним вызывающим. В рамках IoC используются инъекции зависимостей для предоставления пользовательских модулей и других зависимых кодов для фреймворческих подпрограмм, которые "склеивают все вместе". Инъекция зависимостей сильно зависит от каркасов IoC, потому что это механизм, который позволяет им "называть вас".

Контейнеры IoC, такие как Castle Windsor и Structure Map, помогают с внедрением зависимостей, обеспечивая автоматическое создание экземпляров и управление жизненным циклом классов, которые вы регистрируете, включая автоматическое создание экземпляров и впрыск параметров, требуемых зарегистрированными классами. Все это упрощает использование инъекции зависимостей, но не требуется.

Injection Dependency - это механизм гибкости, который максимизирует зависимость от интерфейсов при минимизации зависимости от конкретной реализации. Следовательно, системы, которые используют инъекцию зависимостей, могут поддерживать "подключаемые" классы реализации, которые могут использоваться в зависимости от обстоятельств. Очень большое преимущество этой "подключаемости" заключается в том, что она значительно упрощает создание модульных тестов. Вы можете высмеять объект на необходимый интерфейс, а затем ввести его в тестовый объект.

Итак, IoC - действительно более широкий принцип, а DI - фундаментальный метод внутри. Системы IoC (Голливудский принцип) имеют тенденцию быть довольно сложными, их трудно понять и, следовательно, иметь крутые кривые обучения. DI, с другой стороны, является хорошей практикой для повседневных разработчиков. Я, как правило, предпочитаю понятный и понятный классный, но сложный.

Ответ 2

IoC - это способность изменять выполнение контракта.

DI - это способность обеспечить реализацию.