Ответ
DI (Dependency Injection) обычно внедряют сервисы, утилиты и другие зависимости, которые:
- Имеют сложную логику (API-клиенты, хранилища)
- Требуют мокирования в тестах (сервисы авторизации)
- Должны быть едиными для всего приложения (глобальные конфиги)
Пример с Angular:
@Injectable()
class AuthService {
login() { /* ... */ }
}
@Component({
selector: 'app-login',
template: `...`
})
class LoginComponent {
constructor(private auth: AuthService) {} // DI
}Также через DI часто передают:
- Логгеры
- HTTP-клиенты
- Состояние приложения (Redux/NgRx Store)
- Внешние библиотеки (обёрнутые в сервисы)
Ответ 18+ 🔞
Слушай, а вот этот ваш Dependency Injection, он же не для всего подряд, как некоторые думают. Это не волшебная палочка, чтобы туда-сюда тыкать. Представь себе — ты строишь дом и начинаешь через центральную систему раздачи инструментов таскать каждый кирпич. Ну ёпта, абсурд же!
Внедрять нужно только то, что реально того стоит. Вот смотри:
Во-первых, всякие ёбаные сервисы с мозговыносящей логикой. Допустим, у тебя клиент к какому-нибудь API, который ещё и токены обновляет, и ретраи делает, и чёрт в ступе. Вот его в DI — и все счастливы. Или какой-нибудь AuthService, который везде нужен. Вместо того чтобы его руками таскать, ты просто говоришь: «дай-ка мне сюда эту авторизацию» — и тебе её аккуратно подсовывают.
@Injectable()
class AuthService {
login() { /* тут вся магия с JWT, OAuth и прочей хуетой */ }
}
@Component({
selector: 'app-login',
template: `...`
})
class LoginComponent {
constructor(private auth: AuthService) {} // Всё, приехали. Заказывали авторизацию? Получите.
}Во-вторых, штуки, которые надо мокать в тестах. Ну потому что тестировать твой компонент, который сам себе дергает реальный API — это как проверять работу двигателя, поджигая бензобак. Нахуй надо. Заинжектил — и в тестах подсунул заглушку, которая просто говорит «всё ок, проходи».
В-третьих, всякие глобальные штуки, единые на всё приложение. Ну, конфиги там, логгер, который пишет в три разных места, состояние приложения (этот ваш NgRx Store, который половина народа использует, а вторая половина охуевает от его boilerplate-а).
А ещё часто так делают: берут какую-нибудь левую внешнюю библиотеку, оборачивают её в свой сервис — и вуаля, ты уже не зависишь напрямую от этого монстра. Захотел поменять — поменял в одном месте, а не бегай по всему коду, как угорелый.
Короче, смысл в том, чтобы не превращать конструктор в помойку, куда сваливают всё подряд. «О, а давайте инжекнуть сюда ещё и isButtonDisabled: boolean!» — нет, блядь, не давайте. Для простых пропсов есть @Input(). DI — это для тяжёлой артиллерии, для зависимостей, которые реально являются сервисами, а не просто данными. Всё остальное — чистое распиздяйство и усложнение без причины. Ядрёна вошь!