Поставщики зависимостей

Поставщик зависимостей настраивает инжектор с токеном DI, который этот инжектор использует для предоставления конкретной версии значения зависимости во время выполнения. Инжектор использует конфигурацию провайдера для создания экземпляров зависимостей, которые он внедряет в компоненты, директивы, каналы и другие сервисы.

Вы должны настроить инжектор с провайдером, иначе он не будет знать, как создать зависимость. Самый очевидный способ для инжектора создать экземпляр класса обслуживания - это сам класс. Если вы указываете сам класс обслуживания в качестве маркера провайдера, то по умолчанию поведение инжектора создает экземпляр этого класса с новым ключевым словом.

В следующем типичном примере сам класс Logger предоставляет экземпляр Logger.

providers: [Logger]

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

• Вы можете предоставить замещающий класс.
• Вы можете предоставить похожий на логгер объект.
• Ваш провайдер может вызвать функцию фабрики регистратора.

Провайдерный объектный литерал

Синтаксис поставщика классов - это сокращенное выражение, которое расширяется до конфигурации поставщика, определенной интерфейсом поставщика.

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

providers: [Logger]
[{ provide: Logger, useClass: Logger }]

Расширенная конфигурация провайдера - это литерал объекта с двумя свойствами.

• Свойство обеспечить содержит маркер, который служит ключом как для определения значения зависимости, так и для настройки инжектора.
• Второе свойство - это объект определения провайдера, который сообщает инжектору, как создать значение зависимости. Ключом определения провайдера может быть useClass, как в примере выше. Это также может быть useExisting, useValue или useFactory. Каждый из этих ключей обеспечивает свой тип зависимости, как описано ниже.

Поставщики альтернативных классов

Разные классы могут предоставлять одну и ту же услугу. Например, следующий код говорит инжектору возвращать экземпляр BetterLogger, когда компонент запрашивает регистратор с использованием токена Logger.

[{ provide: Logger, useClass: BetterLogger }]

Провайдеры псевдонимов

Предположим, старый компонент зависит от класса OldLogger. OldLogger имеет тот же интерфейс, что и NewLogger, но по какой-то причине вы не можете обновить старый компонент, чтобы использовать его.

Когда старый компонент регистрирует сообщение с помощью OldLogger, вы хотите, чтобы одноэлементный экземпляр NewLogger обрабатывал его. В этом случае инжектор зависимостей должен внедрить этот единственный экземпляр, когда компонент запрашивает новый или старый регистратор. OldLogger должен быть псевдонимом для NewLogger.

[ NewLogger,
  // Not aliased! Creates two instances of `NewLogger`
  { provide: OldLogger, useClass: NewLogger}]

Чтобы убедиться, что существует только один экземпляр NewLogger, псевдоним OldLogger с опцией useExisting.

[ NewLogger,
  // Alias OldLogger w/ reference to NewLogger
  { provide: OldLogger, useExisting: NewLogger}]

Поставщики стоимости

Иногда проще предоставить готовый объект, чем попросить инжектора создать его из класса. Чтобы добавить объект, который вы уже создали, настройте инжектор с параметром useValue следующим образом:

```[{ provide: Logger, useValue: silentLogger }]```

Неклассовые зависимости

Не все зависимости являются классами. Иногда вы хотите ввести строку, функцию или объект.

Приложения часто определяют объекты конфигурации с множеством мелких фактов, таких как название приложения или адрес конечной точки веб-API. Эти объекты конфигурации не всегда являются экземплярами класса. Они могут быть объектными литералами, как показано в следующем примере.

export const HERO_DI_CONFIG: AppConfig = {
  apiEndpoint: 'api.heroes.com',
  title: 'Dependency Injection'
};

Фабрика провайдеров

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

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

Предыдущий: Внедрение зависимостей в угловых
Далее: Иерархические инжекторы зависимости