学习资料来自 Angular.cn 与 Angular.io。

本章在线例子

依赖注入 (Dependency injection)

依赖注入简称为 DI，它是重要的程序设计模式。DI 可以让类从外部源中获得它的依赖，而不必亲自创建它们。

为什么需要依赖注入？

示例
src/app/car/car.ts (without DI)

export class Car {
  public engine: Engine;
  public tires: Tires;
  public description = 'No DI';
  constructor() {
    this.engine = new Engine();
    this.tires = new Tires();
  }
  // Method using the engine and tires
  drive() {
    return `${this.description} car with ` +
      `${this.engine.cylinders} cylinders and ${this.tires.make} tires.`;
  }
}

这个 Car 类在构造函数中用具体的 Engine 和 Tires 类实例化出自己的副本，它过于脆弱、缺乏弹性并且难以测试。

改进的 DI 版本示例
src/app/car/car.ts (without DI)

export class Car {
  public engine: Engine;
  public tires: Tires;
  public description = 'DI';
  constructor(public engine: Engine, public tires: Tires) { }
  // Method using the engine and tires
  drive() {
    return `${this.description} car with ` +
      `${this.engine.cylinders} cylinders and ${this.tires.make} tires.`;
  }
}

使用这个 DI 版本的示例1：

// Simple car with 4 cylinders and Flintstone tires.
let car = new Car(new Engine(), new Tires());

使用这个 DI 版本的示例2：

class Engine2 {
  constructor(public cylinders: number) { }
}
// Super car with 12 cylinders and Flintstone tires.
let bigCylinders = 12;
let car = new Car(new Engine2(bigCylinders), new Tires());

使用这个 DI 版本的测试：

class MockEngine extends Engine { cylinders = 8; }
class MockTires  extends Tires  { make = 'YokoGoodStone'; }

// Test car with 8 cylinders and YokoGoodStone tires.
let car = new Car(new MockEngine(), new MockTires());

没有注入器 (injector) 时，使用该 DI 类的示例
src/app/car/car-factory.ts

import { Engine, Tires, Car } from './car';
// BAD pattern!
export class CarFactory {
  createCar() {
    let car = new Car(this.createEngine(), this.createTires());
    car.description = 'Factory';
    return car;
  }
  createEngine() {
    return new Engine();
  }
  createTires() {
    return new Tires();
  }
}

应用规模变大之后，该工厂类会变得极其复杂难以维护。

使用依赖注入框架时，注入器可以让事情变得简单：

let car = injector.get(Car);

说明：Car 不需要知道如何创建 Engine 和 Tires。 消费者不需要知道如何创建 Car。 开发人员不需要维护巨大的工厂类。 Car 和消费者只要简单地请求想要什么，注入器就会交付它们。

Angular 依赖注入

配置注入器

不需要创建 Angular 注入器。 Angular 在启动过程中自动为我们创建一个应用级注入器。

示例
src/main.ts (bootstrap)

platformBrowserDynamic().bootstrapModule(AppModule);

我们必须通过注册提供商 (provider) 来配置注入器，这些提供商为应用创建所需服务。

示例1：在 NgModule 中注册提供商
src/app/app.module.ts

@NgModule({
  imports: [
    BrowserModule
  ],
  declarations: [
    AppComponent,
    CarComponent,
    HeroesComponent,
    /* . . . */
  ],
  providers: [
    UserService,
    { provide: APP_CONFIG, useValue: HERO_DI_CONFIG }
  ],
  bootstrap: [ AppComponent ]
})
export class AppModule { }

示例2：在组件中注册提供商
src/app/heroes/heroes.component.ts

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

import { HeroService }        from './hero.service';

@Component({
  selector: 'my-heroes',
  providers: [HeroService],
  template: `
  <h2>Heroes</h2>
  <hero-list></hero-list>
  `
})
export class HeroesComponent { }

该用 NgModule 还是应用组件来注册提供商？

APP_CONFIG 服务需要在应用中到处可用，所以它被注册到 AppModule @NgModule 的 providers 数组是合理的。

HeroService 只在英雄特性区使用，因此在 HeroesComponent 中注册它是合理的。

根据服务使用的范围确定提供商的合理注册位置。

示例 HeroListComponent 从注入的 HeroService 获取英雄数据。
src/app/heroes/hero.service.ts

import { Injectable } from '@angular/core';
import { HEROES }     from './mock-heroes';
@Injectable()
export class HeroService {
  getHeroes() { return HEROES; }
}

src/app/heroes/hero-list.component.ts

import { Component }   from '@angular/core';
import { Hero }        from './hero';
import { HeroService } from './hero.service';
@Component({
  selector: 'hero-list',
  template: `
  <div *ngFor="let hero of heroes">
    {{hero.id}} - {{hero.name}}
  </div>
  `
})
export class HeroListComponent {
  heroes: Hero[];
  constructor(heroService: HeroService) {
    this.heroes = heroService.getHeroes();
  }
}

隐式注入器的创建

可以显式创建注入器，但一般情况下使用隐式创建注入器。

单例服务

在一个注入器的范围内，依赖都是单例的。 在这个例子中，HeroesComponent 和它的子组件 HeroListComponent 共享同一个 HeroService 实例。

Angular DI 是一个分层的依赖注入系统，这意味着嵌套的注入器可以创建它们自己的服务实例。更多内容见多级依赖注入器。

测试组件

示例

let expectedHeroes = [{name: 'A'}, {name: 'B'}]
let mockService = <HeroService> {getHeroes: () => expectedHeroes }

it('should have heroes when HeroListComponent created', () => {
  let hlc = new HeroListComponent(mockService);
  expect(hlc.heroes.length).toEqual(expectedHeroes.length);
});

更多内容见测试。

当服务需要别的服务时

src/app/heroes/hero.service.ts

import { Injectable } from '@angular/core';
import { HEROES }     from './mock-heroes';
import { Logger }     from '../logger.service';
@Injectable()
export class HeroService {
  constructor(private logger: Logger) {  }
  getHeroes() {
    this.logger.log('Getting heroes ...');
    return HEROES;
  }
}

为什么要用 @Injectable()?

@Injectable() 标识一个类可以被注入器实例化。

建议：为每个服务类都添加 @Injectable()。

为什么不标记 HerosComponent 为 @Injectable() 呢？

我们可以添加它，但是没有必要。因为 HerosComponent 已经有 @Component 装饰器了，@Component（@Directive 以及 @Pipe）是 Injectable 的子类型。

创建和注册日志服务

示例：创建日志服务
src/app/logger.service.ts

import { Injectable } from '@angular/core';
@Injectable()
export class Logger {
  logs: string[] = []; // capture logs for testing
  log(message: string) {
    this.logs.push(message);
    console.log(message);
  }
}

示例：注册日志服务
src/app/app.module.ts (excerpt)

providers: [Logger]

注入器的提供商们

提供商提供依赖值的一个具体的、运行时的版本。 注入器依靠提供商创建服务的实例，注入器再将服务的实例注入组件或其它服务。

必须为注入器注册一个服务的提供商，否则它不知道该如何创建该服务。

Provider 类和一个提供商的字面量

注册提供商的简写表达式：

providers: [Logger]

等效的明细写法为：

[{ provide: Logger, useClass: Logger }]

第一个是令牌，它作为键值 (key) 使用，用于定位依赖值和注册提供商。
第二个是一个提供商定义对象。 可以把它看做是指导如何创建依赖值的配方。

备选的类提供商

可以为提供商使用不同的类：

[{ provide: Logger, useClass: BetterLogger }]

带依赖的类提供商

示例：

@Injectable()
class EvenBetterLogger extends Logger {
  constructor(private userService: UserService) { super(); }

  log(message: string) {
    let name = this.userService.user.name;
    super.log(`Message to ${name}: ${message}`);
  }
}

注册提供商：

[ UserService,
  { provide: Logger, useClass: EvenBetterLogger }]

别名类提供商

当旧组件想使用 OldLogger 记录消息时，我们希望改用 NewLogger 的单例对象来记录。不管组件请求的是新的还是旧的日志服务，依赖注入器注入的都应该是同一个单例对象。 也就是说，OldLogger 应该是 NewLogger 的别名。

尝试使用 useClass 会导致意外的后果：

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

正确的做法是使用 useExisting 选项指定别名：

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

值提供商

有时，提供一个预先做好的对象会比请求注入器从类中创建它更容易。

// An object in the shape of the logger service
let silentLogger = {
  logs: ['Silent logger says "Shhhhh!". Provided via "useValue"'],
  log: () => {}
};

可以通过 useValue 选项来注册提供商，它会让这个对象直接扮演 logger 的角色：

[{ provide: Logger, useValue: silentLogger }]

工厂提供商

有时我们需要动态创建这个依赖值，因为它所需要的信息直到最后一刻才能确定。 还假设这个可注入的服务没法通过独立的源访问此信息。这种情况下可调用工厂提供商。

HeroService 必须对普通用户隐藏掉秘密英雄。 只有授权用户才能看到秘密英雄。
与 EvenBetterLogger 不同，不能把 UserService 注入到 HeroService 中。 HeroService 无权访问用户信息，来决定谁有授权谁没有授权。让 HeroService 的构造函数带上一个布尔型的标志，来控制是否显示隐藏的英雄。

示例
src/app/heroes/hero.service.ts (excerpt)

constructor(
  private logger: Logger,
  private isAuthorized: boolean) { }

getHeroes() {
  let auth = this.isAuthorized ? 'authorized ' : 'unauthorized';
  this.logger.log(`Getting heroes for ${auth} user.`);
  return HEROES.filter(hero => this.isAuthorized || !hero.isSecret);
}

我们可以注入 Logger，但是不能注入逻辑型的 isAuthorized。 我们不得不通过工厂提供商创建这个 HeroService 的新实例。

示例
src/app/heroes/hero.service.provider.ts (excerpt)

let heroServiceFactory = (logger: Logger, userService: UserService) => {
  return new HeroService(logger, userService.user.isAuthorized);
};

export let heroServiceProvider =
  { provide: HeroService,
    useFactory: heroServiceFactory,
    deps: [Logger, UserService]
  };

HeroService 不能访问 UserService，但是工厂方法可以。

useFactory 字段告诉 Angular：这个提供商是一个工厂方法，它的实现是 heroServiceFactory
。
deps 属性是提供商令牌数组。 Logger 和 UserService 类作为它们自身类提供商的令牌。 注入器解析这些令牌，把相应的服务注入到工厂函数中相应的参数中去。

更新后的 HeroesComponent 示例
src/app/heroes/heroes.component.ts

import { Component }          from '@angular/core';
import { heroServiceProvider } from './hero.service.provider';
@Component({
  selector: 'my-heroes',
  template: `
  <h2>Heroes</h2>
  <hero-list></hero-list>
  `,
  providers: [heroServiceProvider]
})
export class HeroesComponent { }

依赖注入令牌

当向注入器注册提供商时，实际上是把这个提供商和一个 DI 令牌关联起来了。 注入器维护一个内部的令牌-提供商映射表，这个映射表会在请求依赖时被引用到。 令牌就是这个映射表中的键值。

只要定义一个 HeroService 类型的构造函数参数， Angular 就会知道把跟 HeroService 类令牌关联的服务注入进来：

constructor(heroService: HeroService)

这是一个特殊的规约，因为大多数依赖值都是以类的形式提供的。

非类依赖

如果依赖值不是一个类呢？有时候想要注入的东西是一个字符串，函数或者对象。

示例
src/app/app-config.ts

export interface AppConfig {
  apiEndpoint: string;
  title: string;
}

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

TypeScript 接口不是一个有效的令牌

CONFIG 常量有一个接口：AppConfig。不幸的是，不能把 TypeScript 接口用作令牌：

// FAIL! Can't use interface as provider token
[{ provide: AppConfig, useValue: HERO_DI_CONFIG })]

// FAIL! Can't inject using the interface as the parameter type
constructor(private config: AppConfig){ }

接口只是 TypeScript 设计时 (design-time) 的概念。JavaScript 没有接口。 TypeScript 接口不会出现在生成的 JavaScript 代码中。 在运行期，没有接口类型信息可供 Angular 查找。

InjectionToken

解决方案是为非类依赖定义和使用 InjectionToken 作为提供商令牌。

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

export let APP_CONFIG = new InjectionToken<AppConfig>('app.config');

类型参数，虽然是可选的，但可以向开发者和开发工具传达类型信息。 而且这个令牌的描述信息也可以为开发者提供帮助。

使用这个 InjectionToken 对象注册依赖的提供商：

providers: [{ provide: APP_CONFIG, useValue: HERO_DI_CONFIG }]

这个配置对象可以注入到任何需要它的构造函数中：

constructor(@Inject(APP_CONFIG) config: AppConfig) {
  this.title = config.title;
}

虽然 AppConfig 接口在依赖注入过程中没有任何作用，但它为该类中的配置对象提供了强类型信息。

或者在 ngModule 中提供并注入这个配置对象，如 AppModule：

providers: [
  UserService,
  { provide: APP_CONFIG, useValue: HERO_DI_CONFIG }
],

可选依赖

可以把构造函数的参数标记为 @Optional()，告诉 Angular 该依赖是可选的：

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

constructor(@Optional() private logger: Logger) {
  if (this.logger) {
    this.logger.log(some_message);
  }
}

当使用 @Optional() 时，代码必须准备好如何处理空值。 如果其它的代码没有注册一个 logger，注入器会设置该 logger 的值为空 null。

附录：直接使用注入器

要避免使用此技术，除非确实需要它。参见 [服务定位器模式]。(https://en.wikipedia.org/wiki/Service_locator_pattern)

附录：为什么建议每个文件只放一个类

如果我们蔑视这个建议，并且 —— 比如说 —— 把 HeroService 和 HeroesComponent 组合在同一个文件里， 就得把组件定义放在最后面！ 如果把组件定义在了服务的前面， 在运行时抛出空指针错误。

通过在独立的文件中定义组件和服务，可以完全避免此问题，也不会造成混淆。

总结

依赖注入是一个重要的模式，对模块化设计以及单元测试都起到了很大的作用。

TODO: 烹饪宝典内容待整合

C# 开发者可以阅读 Developer's Guide to Dependency Injection Using Unity 学习了解在 C# 中使用 Unity 实现 DI。