Чем полезно внедрение зависимостей в Angular, поскольку оно ничего не решает?

Question

Как это может улучшить мой код?Как это может удалить зависимость?Я все еще не вижу никакой пользы от использования этого?

@Component({ 
  selector: 'talk-list', 
  templateUrl: 'talks.html', 
  providers: [TalksAppBackend] 
}) 
class TalkList { 
  constructor(backend:TalksAppBackend) { 
    this.talks = backend.fetchTalks(); 
  } 
}

Если бы я использовал

TalksAppBackend t = new TalksAppBackend ();это было бы то же самое.Помимо синтаксической разницы, насколько она отличается?

Обновление:

Также он вызывает .fetchTalks ();это не насмешка.Как это возможно?

Answer 1

Прежде всего, это плохой вопрос для StackOverflow.Но это заслуживает ответа.Итак, вот оно.

Если вы не используете DI

Основное отличие состоит в том, что если вы не используете DI (внедрение зависимостей), тогда ваш код ДОЛЖЕНзнать, как создать все его зависимости.У вас есть тонны компонентов, использующих тонны услуг.Службы могут ретранслироваться на другие службы, например, TalksAppBackend может потребоваться HttpClient услуга.И ваш код должен создавать зависимости для своих зависимостей.Как и

TalksAppBackend t = new TalksAppBackend(new HttpClient())

И каждый ваш компонент должен это делать, создавая новый экземпляр TalksAppBackend и экземпляр HttpClient.И если позже TalksAppBackend потребуется некоторая служба ведения журналов, вы должны вручную обновить все ваши компоненты, чтобы создать все декы для TalksAppBackend.Такой код трудно поддерживать, и он использует больше памяти, чем следовало бы, потому что он не разделяет экземпляры.

Если вы используете DI

Вы просто указываете модуль иликомпонент, который отвечает за создание экземпляра желаемой зависимости.Это позаботится и о его зависимостях.Ваши компоненты могут просто указать желаемый класс TalksAppBackend для инъекции и не должны заботиться о том, требует ли он HttpClient или Logger или что-то еще.DI делает эту работу.И у вас есть прекрасный контроль над этим: глобальная служба, предоставляемая модулем, будет создана только один раз.Таким образом, ваши компоненты могут использовать один и тот же экземпляр.И если вы хотите, вы можете предоставить его на уровне компонентов, чтобы можно было создать много экземпляров, и дочерние компоненты будут иметь доступ к единственному необходимому экземпляру.

И этот подход также открывает путь для насмешки.зависимости и предоставляют не реальную TalksAppBackend услугу, а скорее имитацию с поддельными ответами, которая не требует сетевого взаимодействия и запуска бэкэнда, чтобы проверить, правильно ли ваш компонент интерпретирует результаты.И вы можете сделать это без изменения кода вашего компонента.Таким образом, в этом подходе компонент ориентирован на то, что он должен делать ТОЛЬКО.

Answer 2

В этом есть много преимуществ.

1. код с новым ключевым словом трудно протестировать в большом приложении.
2. важно: рассмотрим создание экземпляра класса с новым ключевым словом.И через несколько дней вы захотите изменить / добавить параметры в конструктор зависимого класса.Затем вам нужно изменить свой код, где бы вы ни использовали экземпляр того же класса.это будет огромная проблема в большом проекте
3. Экземпляры зависимостей, созданные классом, которому нужны эти зависимости, являются локальными для класса и не могут совместно использовать данные и логику

Answer 3

Хороший вопрос.Там много преимуществ от этого.Вы можете прочитать об этом на эту же тему в AngularJS здесь: Каковы преимущества внедрения зависимости AngularJS?

Но для меня ключ - это тесты.Если вы выполняете модульные тесты этого компонента, вы можете ввести easilly макет TalksAppBackend, а затем изолировать компонент от их зависимости в модульном тесте.Введя в код TalksAppBackend t= new TalksAppBackend();, вы не сможете выполнить его модульное тестирование.