Dependency Injection

Mục lụcCopy Anchor Link

• Dependency Injection là gì?
  • Bài toán khi không dùng DI
  • Ba vai trò: token, provider và injector
• Cơ chế phân giải: cây injector
  • Thứ tự tìm provider
  • Vòng đời instance
• Yêu cầu dependency bằng constructor và inject()
  • Injection context
  • Các cờ phân giải
• Khai báo provider và token
  • providedIn cho service mặc định
  • Các chiến lược provider
  • Multi provider
• Scope: đặt provider ở đâu?
• Ví dụ hoàn chỉnh: cấu hình và repository
• Kiểm thử dependency
• Lỗi thường gặp và cách chẩn đoán
• Trade-off và quy ước thiết kế
• Tóm tắt

Dependency Injection là gì?Copy Anchor Link

Dependency Injection (DI) là cơ chế để một đối tượng khai báo thứ nó cần, còn Angular tìm và đưa instance phù hợp vào đối tượng đó. Dependency có thể là service, cấu hình, hàm chiến lược, HTTP client hoặc một giá trị như URL API.

Ví dụ, OrderService cần ghi log. Nó không nên biết cách tạo ConsoleLogger hay RemoteLogger; nó chỉ yêu cầu Logger. Quyết định dùng implementation nào nằm ở cấu hình provider.

Bài toán khi không dùng DICopy Anchor Link

Không dùng DI, một class thường tự tạo dependency:

class OrderService {
  private logger = new ConsoleLogger();
}

Cách này ghép chặt OrderService với ConsoleLogger. Khi cần đổi sang logger gửi về server hoặc dùng fake logger trong test, code nghiệp vụ phải sửa hoặc phải tạo thêm nhánh điều kiện.

Với DI, class chỉ phụ thuộc vào một hợp đồng:

class OrderService {
  constructor(private readonly logger: Logger) {}
}

Provider quyết định Logger thực tế là gì. Vì vậy dependency có thể thay thế tại ranh giới ứng dụng, route hoặc component mà không sửa OrderService.

Ba vai trò: token, provider và injectorCopy Anchor Link

Một token là định danh theo object/reference, không chỉ theo tên hiển thị. InjectionToken giúp biểu diễn dependency không có class runtime, chẳng hạn interface TypeScript hoặc chuỗi cấu hình.

Cơ chế phân giải: cây injectorCopy Anchor Link

Angular dùng hai chuỗi injector khi phân giải dependency:

• ElementInjector gắn với phần tử/component/directive trong cây view. providers của component hoặc directive nằm ở đây.
• EnvironmentInjector chứa provider không gắn với một component cụ thể. bootstrapApplication tạo injector cấp application. Route chỉ có providers mới tạo thêm một EnvironmentInjector con cho route đó.

Các EnvironmentInjector không phải là một injector duy nhất chứa tất cả provider. Chúng là chuỗi cha-con: injector của route (nếu có) → injector application → platform injector. Mỗi injector chỉ giữ provider thuộc scope của nó; không tìm thấy thì Angular mới hỏi injector cha.

Khi component hoặc directive yêu cầu một token, Angular tìm trong ElementInjector hiện tại trước, rồi đi lên các ElementInjector tổ tiên. Nếu vẫn không có provider, Angular tiếp tục theo chuỗi EnvironmentInjector: route hiện tại → application → platform. Nếu đến NullInjector mà vẫn không tìm thấy token, Angular ném NullInjectorError.

direction: right

n0: "Component con\nYêu cầu AUTH_API" {
  width: 152
  height: 58
}

n1: "ElementInjector\ncheckout-page\nproviders:\nCheckoutSession" {
  width: 144
  height: 100
}

n2: "ElementInjector\napp-root\nproviders:\nThemeService" {
  width: 144
  height: 100
}

n3: "Route\nEnvironmentInjector\nChỉ khi route có\nproviders\nproviders: OrderDraft" {
  width: 192
  height: 121
}

n0 -> n1
n1 -> n2
n2 -> n3

direction: right

n3: "Route\nEnvironmentInjector\nChỉ khi route có\nproviders\nproviders: OrderDraft" {
  width: 192
  height: 121
}

n4: "App\nEnvironmentInjector\nHttpClient, API_URL,\nAUTH_API\nCó AUTH_API: trả\ninstance" {
  width: 184
  height: 142
}

n5: "Platform injector\nProvider nền tảng" {
  width: 160
  height: 58
}

n6: "NullInjector\nKhông có provider:\nNullInjectorError" {
  width: 168
  height: 79
}

n3 -> n4
n4 -> n5
n5 -> n6

Tra cứu dừng ngay khi tìm thấy provider. Chỉ tiếp tục lên injector kế tiếp nếu cấp hiện tại không cung cấp token; Platform injector thường ít được ứng dụng tự cấu hình.

Thứ tự tìm providerCopy Anchor Link

Với dependency được inject từ một component/directive, Angular ưu tiên provider cục bộ trên element hiện tại. Nếu không có, nó tìm các ElementInjector tổ tiên rồi tiếp tục sang chuỗi EnvironmentInjector thích hợp. Provider gần nhất che khuất provider cùng token ở cấp cha.

Ví dụ, UserPreferences ở root là singleton cho ứng dụng. Nếu ProfileEditorComponent có providers: [UserPreferences], component này và các component con của nó dùng instance khác. Các nơi khác vẫn dùng instance root.

Điều này cho phép cô lập state theo một nhánh UI, nhưng cũng có thể tạo ra lỗi khó thấy khi vô tình đăng ký cùng một stateful service ở component.

Vòng đời instanceCopy Anchor Link

Injector thường tạo instance khi token được yêu cầu lần đầu, rồi giữ lại trong cache của scope đó. Không nên dựa vào thời điểm chính xác này để chạy nghiệp vụ; constructor nên chỉ thiết lập dependency và trạng thái nhẹ.

Khi injector bị hủy, Angular hủy các service do injector đó tạo. Một service có ngOnDestroy() sẽ nhận lifecycle hook này. DestroyRef là lựa chọn thuận tiện để đăng ký cleanup ngay trong nơi inject service.

import { DestroyRef, Injectable, inject } from '@angular/core';

@Injectable()
export class LiveUpdatesService {
  private readonly destroyRef = inject(DestroyRef);
  private readonly socket = new WebSocket('wss://example.test/updates');

  constructor() {
    this.destroyRef.onDestroy(() => this.socket.close());
  }
}

Provider ở component bị hủy khi component đó bị hủy. Provider ở route-level injector sống trong thời gian route injector còn tồn tại. Provider ở root thường sống đến khi toàn bộ ứng dụng bị hủy.

Yêu cầu dependency bằng constructor và inject()Copy Anchor Link

Angular hỗ trợ hai cú pháp chính. Cả hai đều yêu cầu injector phân giải token, khác nhau ở vị trí khai báo dependency.

import { Component, inject } from '@angular/core';
import { CartService } from './cart.service';

@Component({
  selector: 'app-cart-summary',
  template: `{{ cart.total() }}`,
})
export class CartSummaryComponent {
  // inject() phù hợp với field initializer và giữ kiểu không-null.
  protected readonly cart = inject(CartService);

  // Constructor injection vẫn hoàn toàn hợp lệ, nhất là với class cũ.
  constructor() {
    // Không cần tự tạo CartService.
  }
}

Cùng class trên có thể dùng constructor injection:

export class CartSummaryComponent {
  constructor(protected readonly cart: CartService) {}
}

Chọn một kiểu nhất quán trong một codebase. inject() thường gọn hơn với field private/protected, function provider và base class. Constructor injection biểu đạt dependency ngay trong chữ ký constructor và quen thuộc với code Angular trước đây.

Injection contextCopy Anchor Link

inject() chỉ hoạt động trong injection context: lúc Angular tạo component, directive, pipe, service; trong field initializer/constructor của các class đó; hoặc trong factory provider. Angular biết injector hiện tại ở những thời điểm này.

Ví dụ hợp lệ trong factory:

import { inject } from '@angular/core';

export const authHeaderProvider = {
  provide: AUTH_HEADER,
  useFactory: () => {
    const session = inject(SessionService);
    return () => `Bearer ${session.token()}`;
  },
};

Ví dụ sau không hợp lệ vì ngOnInit chạy sau khi Angular đã rời injection context:

export class InvalidComponent {
  ngOnInit() {
    const api = inject(CatalogApi); // NG0203
    api.load();
  }
}

Hãy inject vào field trước, rồi dùng field trong hook. Với hàm tiện ích thực sự cần context, truyền dependency vào hàm là cách rõ ràng nhất. runInInjectionContext() chỉ nên dùng khi bạn đang chủ động thiết lập context từ một EnvironmentInjector đã biết.

Các cờ phân giảiCopy Anchor Link

inject() nhận options để thay đổi phạm vi tìm kiếm. Đây là công cụ cho các tình huống đặc biệt, không phải mặc định.

Dùng optional chỉ khi null là một trạng thái nghiệp vụ được xử lý. Dùng nó để “chữa” NullInjectorError sẽ chuyển lỗi cấu hình thành null khó truy vết hơn.

Khai báo provider và tokenCopy Anchor Link

providedIn cho service mặc địnhCopy Anchor Link

Với service dùng toàn ứng dụng, khai báo provider ngay tại decorator:

import { Injectable } from '@angular/core';

@Injectable({ providedIn: 'root' })
export class AuditService {
  record(event: string): void {
    console.log(event);
  }
}

providedIn: 'root' đăng ký service ở root environment injector và cho phép tree-shaking khi service không được dùng. Đây là mặc định tốt cho service stateless hoặc state dùng chung toàn ứng dụng.

providedIn: 'platform' đưa service lên platform injector, nên có thể được chia sẻ giữa nhiều Angular application cùng trang. Phạm vi này hiếm dùng; shared state giữa micro-frontend có thể gây ghép nối và khó dọn dẹp.

Các chiến lược providerCopy Anchor Link

Provider có thể trả class, giá trị, kết quả factory hoặc alias cho token khác.

import { ApplicationConfig, InjectionToken, inject } from '@angular/core';

export interface AppConfig {
  apiUrl: string;
  enableAudit: boolean;
}

export const APP_CONFIG = new InjectionToken<AppConfig>('app.config');
export const API_BASE_URL = new InjectionToken<string>('api.base-url');

export const appConfig: ApplicationConfig = {
  providers: [
    // useValue: giá trị đã có, thường là cấu hình hoặc fake test.
    { provide: APP_CONFIG, useValue: { apiUrl: '/api', enableAudit: true } },

    // useClass: một implementation cho một token/hợp đồng.
    { provide: PaymentGateway, useClass: StripePaymentGateway },

    // useExisting: alias; cả hai token trả cùng một instance.
    { provide: LegacyAuditService, useExisting: AuditService },

    // useFactory: tính giá trị từ các dependency khác.
    {
      provide: API_BASE_URL,
      useFactory: () => `${inject(APP_CONFIG).apiUrl}/v1`,
    },
  ],
};

useExisting khác useClass: useClass tạo một instance theo provider của nó, còn useExisting chỉ đặt thêm tên cho instance hiện có. Nếu cần giữ chung state, dùng useExisting.

useFactory phù hợp khi cách tạo dependency phụ thuộc môi trường hoặc token khác. Factory nên ngắn, không có side effect khó kiểm soát và chỉ lấy dependency qua tham số deps hoặc inject() trong chính factory.

Multi providerCopy Anchor Link

Đặt multi: true để nhiều provider cùng đóng góp vào một token. Injector trả về mảng theo các provider đã đăng ký thay vì một giá trị đơn lẻ.

import { InjectionToken } from '@angular/core';

export type ValidationRule = (value: string) => string | null;
export const VALIDATION_RULES = new InjectionToken<ValidationRule[]>('validation.rules');

export const validationProviders = [
  {
    provide: VALIDATION_RULES,
    multi: true,
    useValue: (value: string) => value ? null : 'Không được để trống',
  },
  {
    provide: VALIDATION_RULES,
    multi: true,
    useValue: (value: string) => value.length >= 8 ? null : 'Tối thiểu 8 ký tự',
  },
];

Multi provider hợp với plugin, interceptor và rule mở rộng. Toàn bộ provider của một token phải nhất quán: không trộn provider multi: true với provider đơn cho cùng token trong cùng phạm vi.

Scope: đặt provider ở đâu?Copy Anchor Link

Scope quyết định ai chia sẻ instance và khi nào nó bị hủy. Chọn scope theo quyền sở hữu state, không chỉ theo sự tiện tay.

Ví dụ tạo state mới cho mỗi editor:

import { Component } from '@angular/core';
import { DraftStore } from './draft.store';

@Component({
  selector: 'app-article-editor',
  providers: [DraftStore],
  template: `<!-- mọi child của editor dùng cùng DraftStore này -->`,
})
export class ArticleEditorComponent {}

Mỗi <app-article-editor> có một DraftStore riêng. Đây là lý do đúng để đặt provider ở component. Ngược lại, đặt HttpClient hoặc AuthService ở đây thường là sai vì làm tách cache/session và tạo instance thừa.

viewProviders cũng đặt provider ở component nhưng chỉ cho component và view children của template của nó; projected content không thấy provider này. Dùng nó khi implementation là chi tiết nội bộ của view component, còn lại ưu tiên providers vì dễ hiểu hơn.

Ví dụ hoàn chỉnh: cấu hình và repositoryCopy Anchor Link

Ví dụ dưới đây tách URL API (configuration) khỏi repository (logic truy cập dữ liệu). Repository chỉ biết token CATALOG_API; production và test có thể cung cấp giá trị khác nhau.

import { Injectable, InjectionToken, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

export interface Product {
  id: string;
  name: string;
}

export const CATALOG_API = new InjectionToken<string>('catalog.api');

@Injectable({ providedIn: 'root' })
export class CatalogRepository {
  private readonly http = inject(HttpClient);
  private readonly apiUrl = inject(CATALOG_API);

  list(): Observable<Product[]> {
    return this.http.get<Product[]>(`${this.apiUrl}/products`);
  }
}

Provider của ứng dụng có thể đặt endpoint thật:

import { ApplicationConfig } from '@angular/core';
import { provideHttpClient } from '@angular/common/http';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(),
    { provide: CATALOG_API, useValue: 'https://api.example.com/catalog' },
  ],
};

CatalogRepository không đọc environment trực tiếp. Ranh giới DI giúp cấu hình rõ ở bootstrap và cho phép test thay endpoint hoặc fake repository mà không sửa business code.

Kiểm thử dependencyCopy Anchor Link

TestBed tạo injector độc lập cho test. Khai báo các provider cần thiết, rồi lấy class dưới test bằng TestBed.inject().

import { TestBed } from '@angular/core/testing';
import { provideHttpClient } from '@angular/common/http';
import { HttpTestingController, provideHttpClientTesting } from '@angular/common/http/testing';

describe('CatalogRepository', () => {
  let repository: CatalogRepository;
  let http: HttpTestingController;

  beforeEach(() => {
    TestBed.configureTestingModule({
      providers: [
        provideHttpClient(),
        provideHttpClientTesting(),
        CatalogRepository,
        { provide: CATALOG_API, useValue: 'http://test/catalog' },
      ],
    });

    repository = TestBed.inject(CatalogRepository);
    http = TestBed.inject(HttpTestingController);
  });

  it('gọi endpoint từ token', () => {
    repository.list().subscribe();

    const request = http.expectOne('http://test/catalog/products');
    expect(request.request.method).toBe('GET');
    request.flush([]);
  });
});

Nếu service đã có providedIn: 'root', TestBed vẫn có thể thay provider trước khi inject:

TestBed.configureTestingModule({
  providers: [{ provide: CATALOG_API, useValue: 'http://fake/catalog' }],
});

TestBed.overrideProvider(CATALOG_API, {
  useValue: 'http://override/catalog',
});

Gọi overrideProvider trong giai đoạn setup, trước khi dependency được tạo. Với provider đặt ở component, test component để lấy đúng ElementInjector; TestBed.inject() chỉ nhìn injector test/root nên có thể không phản ánh instance cục bộ của component.

Lỗi thường gặp và cách chẩn đoánCopy Anchor Link

Một quy trình chẩn đoán ngắn:

1. Xác định token thực tế tại điểm inject, không chỉ tên class/interface.
2. Tìm provider gần nhất của token đó: decorator, application config, route, component hay directive.
3. Xác định injector đang yêu cầu token có đi lên được scope chứa provider không.
4. Kiểm tra xem provider gần hơn có che khuất provider bạn mong đợi không.
5. Với test, xác minh thứ tự configureTestingModule → overrideProvider → inject/createComponent.

Trade-off và quy ước thiết kếCopy Anchor Link

DI làm giảm ghép nối trực tiếp, nhưng cũng làm dependency trở thành cấu hình gián tiếp. Một class có thể dễ test hơn, song quá nhiều token và factory khiến đường đi của dữ liệu khó đọc hơn.

Một class nhận quá nhiều dependency thường là tín hiệu nó đang gánh nhiều trách nhiệm. Đừng che dấu vấn đề bằng inject() ở hàng loạt field; hãy cân nhắc tách use case hoặc gom một nhóm dependency có quan hệ chặt thành một facade có ý nghĩa.

Tóm tắtCopy Anchor Link

• Token định danh dependency; provider mô tả cách tạo nó; injector phân giải và lưu instance theo scope.
• Injector gần nhất thắng. Đặt provider ở root, route hay component là quyết định về quyền sở hữu state và lifecycle.
• Dùng constructor hoặc inject() trong injection context. Không gọi inject() trong lifecycle hook hay callback thông thường.
• Dùng InjectionToken cho interface, cấu hình và primitive; chọn useValue, useClass, useExisting, useFactory hoặc multi theo mục đích.
• Trong test, cấu hình/override provider trước khi tạo service hoặc component; chú ý provider cục bộ của component có thể che root provider.