学习资料来自 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。
网友评论