Основы внедрения зависимостей: почему меня это волнует? - PullRequest
Новая
       5

Основы внедрения зависимостей: почему меня это волнует?

18 голосов
/ 04 июня 2009

Я читал более Инъекция вручную и Инъекция (а также Зачем использовать Ninject ). Я столкнулся с двумя частями путаницы:

  1. Техника ввода вручную, с которой я уже знаком, но я не знаком с Ninjection, и поэтому не уверен, как будет работать вся программа. Возможно, это поможет предоставить полную программу, а не, как это делается на этой странице, показать программу, разбитую на части

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

Ответы [ 7 ]

6 голосов
/ 04 июня 2009

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

    public Contact()
        : this(new DataGateWay())
    {
    }

Но если вы используете что-то вроде Ninject, весь код стрелки находится в одном месте, что облегчает изменение зависимости для всех классов, использующих его. 

internal class ProductionModule : StandardModule
{
    public override void Load()
    {
        Bind<IDataGateway>().To<DataGateWay>();
    }
}
4 голосов
/ 07 июня 2009

Я до сих пор не понимаю, как это облегчает жизнь. Я думаю, что упускаю что-то важное.

Не было бы замечательно, если бы нам нужно было разрабатывать только отдельные компоненты, каждый из которых предоставлял отличную функциональность, которую мы могли бы легко понять, повторно использовать и поддерживать. Где мы только работали над компонентами.

Что мешает нам сделать это, так это то, что нам нужна инфраструктура, которая может каким-то образом объединять и управлять этими компонентами в работающее приложение автоматически . Инфраструктура, которая делает это, доступна нам - инфраструктура МОК.

Таким образом, структура IOC не о управлении зависимостями или тестированием или настройкой. Вместо этого это о управлении сложностью, позволяя вам работать только и думать о компонентах.

3 голосов
/ 04 июня 2009

Это позволяет вам легко тестировать ваш код, высмеивая интерфейсы, которые вам нужны для определенного блока кода. Это также позволяет вам легко менять функциональность, не нарушая другие части кода.

Это все о сплоченности и сцеплении.

Вы, вероятно, не увидите выгоды от небольших проектов, но как только вы доберетесь до малого, станет действительно очевидным, когда вам придется вносить изменения в систему. Это легкий ветерок, когда ты использовал DI.

2 голосов
/ 04 июня 2009

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

EDIT: Я прочитал эту статью Ayende @ Rahien . И я действительно поддерживаю его точку зрения.

1 голос
/ 04 июня 2009

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

0 голосов
/ 04 июня 2009

Внедрение зависимостей необходимо для Компонентно-управляемой разработки . Последнее позволяет создавать действительно сложных приложения гораздо более эффективным и надежным способом.

Кроме того, он позволяет четко отделить общие сквозные задачи от другого кода (это приводит к более многократно используемой и гибкой базе кода).

Ссылки по теме:

0 голосов
/ 04 июня 2009

Внедрение зависимостей может стать действительно интересным, если вы доведите свой код до точки, где в коде совсем немного зависимостей. Некоторые структуры внедрения зависимостей позволят вам определить ваши зависимости в файле конфигурации. Это может быть очень полезно, если вам нужно действительно гибкое программное обеспечение, которое нужно менять без изменения кода. Например, программное обеспечение документооборота является основным кандидатом для такого типа решений.

...