一个常见的误解是，@Injectable() 是我们计划在应用程序中注入组件/服务的任何类的必需装饰器。 这种说法并不完全正确。
当使用 Angular 装饰器时，被装饰的类以 Angular 可以读取的格式存储关于自身的元数据——这包括关于它需要获取和注入哪些依赖项的元数据。
如果一个类上没有使用 Angular 装饰器，那么 Angular 就无法读取它需要的依赖项。 这就是我们需要使用@Injectable() 的原因。
如果我们的服务注入提供者，我们必须添加 @Injectable()，这个注解除了告诉 Angular 存储它需要的元数据之外，没有实现其他额外的功能。
假设我们有下面这个 Service class：
export class UserService {
isAuthenticated(): boolean {
return true;
}
}
对于上面这个类，我们不需要用 @Injectable装饰它，以便能够将其注入到组件中。因为 UserService 本身不注入任何 providers.
然而如果我们的 Service 类本身又注入了其他的依赖：
import { Http } from '@angular/http';
export class UserService {
constructor(private http: Http) {}
isAuthenticated(): Observable<boolean> {
return this.http.get('/api/user').map((res) => res.json());
}
}
上面的代码无法正常工作，因为 Http 提供程序元数据不会被存储以供 Angular 正确组合。
解决方案就是使用 @Injectable 注解：
import { Injectable } from '@angular/core';
import { Http } from '@angular/http';
@Injectable()
export class UserService {
constructor(private http: Http) {}
isAuthenticated(): Observable<boolean> {
return this.http.get('/api/user').map((res) => res.json());
}
}
SAP Spartacus 的例子：
对于用于 DI 的控制反转 (IOC) 容器，开发人员通常需要完成两种设置。 首先是令牌。 要向 IOC 容器注册依赖，需要提供一个令牌。 令牌是注册任何服务的独一无二的标识符。 第二件事是配置 provider 本身。 提供者帮助 DI 容器创建特定依赖项的运行时实例。
在 Angular 中，使用令牌注册服务，并将其传递给提供者的具体方法如下所述：
首先，可以使用特定的@NgModule 注册服务。 该过程是通过将服务传递给提供者数组来进行注册。 下面是一个例子，使用的令牌是 typescript 类型 MyService. 这里的提供者是 useClass. 这个提供者策略，通知 Angular DI 框架，可以通过 new 关键字来实例化某个依赖项。
例子代码：
@NgModule({
...
providers: [
// long hand syntax
{provide: MyService, useClass: MyService},
// short hand syntax
MyService
],
})
注意上面提供了两种语法，因为 provide 和 useClass 指向的 type 定义相同，所以可以直接简写成 MyService.
网友评论