Cet article vous permettra de parler de Angular et de présenter le concept de base de l'injection de dépendances. J'espère qu'il sera utile à tout le monde !
En tant que framework front-end conçu "pour les projets front-end à grande échelle", Angular propose en fait de nombreuses conceptions qui méritent d'être référencées et apprises. Cette série est principalement utilisée pour étudier les principes de mise en œuvre de ces conceptions et fonctions. Cet article se concentre sur la plus grande fonctionnalité d'Angular : l'injection de dépendances. Tout d'abord, nous présenterons quelques concepts de base dans le système d'injection de dépendances Angular.
Puisque nous allons présenter la conception de l'injection de dépendances du framework Angular, jetons d'abord les bases du concept de base de l'injection de dépendances. Nous confondons souvent les concepts de principe d'inversion de dépendance (DIP), d'inversion de contrôle (IoC) et d'injection de dépendance (DI), nous les présenterons donc brièvement ici. [Recommandations du didacticiel associé : "Tutoriel angulaire"]
Un faible couplage et une cohésion élevée sont probablement l'un des objectifs de conception de chaque système, et pour cette raison, il Il existe de nombreux modèles et concepts de conception, y compris les idées de conception du principe d'inversion de dépendance et d'inversion de contrôle.
(1) Principe d'inversion de dépendance (DIP).
La définition originale du principe d'inversion de dépendance est :
Pour faire simple : les modules ne doivent pas dépendre directement les uns des autres, mais doivent s'appuyer sur une règle abstraite (interface ou classe abstraite).
(2) Inversion de contrôle (IoC).
La définition de l'inversion de contrôle est la suivante : les dépendances entre modules sont instanciées et gérées de l'intérieur du programme vers l'extérieur. Autrement dit, lorsqu'un objet est créé, il est contrôlé par une entité externe qui contrôle tous les objets du système, et les références des objets dont il dépend lui sont transmises (injectées).
Il existe deux manières principales d'implémenter l'inversion de contrôle :
(3) Injection de dépendances.
L'injection de dépendances est la technique d'inversion de contrôle la plus courante.
L'inversion de dépendance et l'inversion de contrôle se complètent et peuvent souvent être utilisées ensemble pour réduire efficacement le couplage entre les modules.
Dans Angular, la technologie d'injection de dépendances est également utilisée. Lors de l'instanciation d'une classe, le framework DI lui fournira les dépendances déclarées par la classe (dépendances : font référence au moment où la classe a besoin d'un service ou d'un objet requis. pour remplir sa fonction).
L'injection de dépendances dans Angular tourne essentiellement autour de composants ou de modules et est principalement utilisée pour fournir des dépendances pour les composants nouvellement créés.
Le principal mécanisme d'injection de dépendances dans Angular est le mécanisme d'injecteur :
Cela implique principalement deux concepts, à savoir Injecteur injecteur et Fournisseur fournisseur, Jetons un coup d'œil.
Injector est utilisé pour créer des dépendances, maintenir un conteneur pour gérer ces dépendances et les réutiliser autant que possible. L'injecteur fournira un singleton de la dépendance et injectera cet objet singleton dans plusieurs composants.
Évidemment, en tant que conteneur utilisé pour créer, gérer et maintenir des dépendances, la fonction de l'injecteur est simple : créer des instances de dépendance, obtenir des instances de dépendance et gérer des instances de dépendance. Nous pouvons également le voir à partir du code source de la classe abstraite Injector
: Injector
的源码中看出来:
export abstract class Injector { // 找不到依赖 static THROW_IF_NOT_FOUND = THROW_IF_NOT_FOUND; // NullInjector 是树的顶部 // 如果你在树中向上走了很远,以至于要在 NullInjector 中寻找服务,那么将收到错误消息,或者对于 @Optional(),返回 null static NULL: Injector = new NullInjector(); // 根据提供的 Token 从 Injector 检索实例 abstract get<T>( token: Type<T> | AbstractType<T> | InjectionToken<T>, notFoundValue?: T, flags?: InjectFlags ): T; // 创建一个新的 Injector 实例,该实例提供一个或多个依赖项 static create(options: { providers: StaticProvider[]; parent?: Injector; name?: string; }): Injector; // ɵɵdefineInjectable 用于构造一个 InjectableDef // 它定义 DI 系统将如何构造 Token,并且在哪些 Injector 中可用 static ɵprov = ɵɵdefineInjectable({ token: Injector, providedIn: "any" as any, // ɵɵinject 生成的指令:从当前活动的 Injector 注入 Token factory: () => ɵɵinject(INJECTOR), }); static __NG_ELEMENT_ID__ = InjectorMarkers.Injector; }
也就是说,我们可以将需要共享的依赖实例添加到注入器中,并通过 Token 查询和检索注入器来获取相应的依赖实例。
需要注意的是,Angular 中的注入器是分层的,因此查找依赖的过程也是向上遍历注入器树的过程。
这是因为在 Angular 中,应用是以模块的方式组织的,具体可以参考5.模块化组织篇。一般来说,页面的 DOM 是以html
// 创建一个新的 Injector 实例,可传入 parent 父注入器 static create(options: {providers: StaticProvider[], parent?: Injector, name?: string}): Injector;
html
comme nœud racine. Sur cette base, les composants et modules de l'application Angular se trouvent également dans une structure arborescente qui l'accompagne. 🎜🎜L'injecteur sert de composants et de modules, et est également monté dans une arborescence de modules et d'organisations. Par conséquent, Injector est également divisé en niveaux de module et de composant, qui peuvent fournir des instances spécifiques de dépendances pour les composants et les modules respectivement. Les injecteurs sont héritables, ce qui signifie que si l'injecteur spécifié ne peut pas résoudre une dépendance, il demandera à l'injecteur parent de la résoudre, comme nous pouvons également le voir dans le code ci-dessus pour créer l'injecteur : 🎜// 创建一个新的 Injector 实例,可传入 parent 父注入器 static create(options: {providers: StaticProvider[], parent?: Injector, name?: string}): Injector;
在某个注入器的范围内,服务是单例的。也就是说,在指定的注入器中最多只有某个服务的最多一个实例。如果不希望在所有地方都使用该服务的同一个实例,则可以通过注册多个注入器、并按照需要关联到组件和模块中的方式,来按需共享某个服务依赖的实例。
我们可以看到创建一个新的Injector
实例时,传入的参数包括Provider
,这是因为Injector
不会直接创建依赖,而是通过Provider
来完成的。每个注入器会维护一个提供者的列表,并根据组件或其它服务的需要,用它们来提供服务的实例。
Provider 提供者用来告诉注入器应该如何获取或创建依赖,要想让注入器能够创建服务(或提供其它类型的依赖),必须使用某个提供者配置好注入器。
一个提供者对象定义了如何获取与 DI 令牌(token) 相关联的可注入依赖,而注入器会使用这个提供者来创建它所依赖的那些类的实例。
关于 DI 令牌:
- 当使用提供者配置注入器时,就会把提供者和一个 DI 令牌关联起来;
- 注入器维护一个内部令牌-提供者的映射表,当请求一个依赖项时就会引用它,令牌就是这个映射表的键。
提供者的类型很多,从官方文档中可以阅读它们的具体定义:
export type Provider = | TypeProvider | ValueProvider | ClassProvider | ConstructorProvider | ExistingProvider | FactoryProvider | any[];
提供者的解析过程如下:
function resolveReflectiveFactory( provider: NormalizedProvider ): ResolvedReflectiveFactory { let factoryFn: Function; let resolvedDeps: ReflectiveDependency[]; if (provider.useClass) { // 使用类来提供依赖 const useClass = resolveForwardRef(provider.useClass); factoryFn = reflector.factory(useClass); resolvedDeps = _dependenciesFor(useClass); } else if (provider.useExisting) { // 使用已有依赖 factoryFn = (aliasInstance: any) => aliasInstance; // 从根据 token 获取具体的依赖 resolvedDeps = [ ReflectiveDependency.fromKey(ReflectiveKey.get(provider.useExisting)), ]; } else if (provider.useFactory) { // 使用工厂方法提供依赖 factoryFn = provider.useFactory; resolvedDeps = constructDependencies(provider.useFactory, provider.deps); } else { // 使用提供者具体的值作为依赖 factoryFn = () => provider.useValue; resolvedDeps = _EMPTY_LIST; } // return new ResolvedReflectiveFactory(factoryFn, resolvedDeps); }
根据不同类型的提供者,通过解析之后,得到由注入器 Injector 使用的提供者的内部解析表示形式:
export interface ResolvedReflectiveProvider { // 键,包括系统范围内的唯一 id,以及一个 token key: ReflectiveKey; // 可以返回由键表示的对象的实例的工厂函数 resolvedFactories: ResolvedReflectiveFactory[]; // 指示提供者是多提供者,还是常规提供者 multiProvider: boolean; }
提供者可以是服务类ClassProvider
本身,如果把服务类指定为提供者令牌,那么注入器的默认行为是用new
来实例化那个类。
在 Angular 中,服务就是一个带有@Injectable
装饰器的类,它封装了可以在应用程序中复用的非 UI 逻辑和代码。Angular 把组件和服务分开,是为了增进模块化程度和可复用性。
用@Injectable
标记一个类,以确保编译器将在注入类时生成必要的元数据(元数据在 Angular 中也是很重要的一部分),以创建类的依赖项。
@Injectable
装饰器的类会在编译之后,得到 Angular 可注入对象:
// 根据其 Injectable 元数据,编译 Angular 可注入对象,并对结果进行修补 export function compileInjectable(type: Type<any>, srcMeta?: Injectable): void { // 该编译过程依赖 @angular/compiler // 可参考编译器中的 compileFactoryFunction compileInjectable 实现 }
Angular 中可注入对象(InjectableDef
)定义 DI 系统将如何构造 token 令牌,以及在哪些注入器(如果有)中可用:
export interface ɵɵInjectableDef<T> { // 指定给定类型属于特定注入器,包括 root/platform/any/null 以及特定的 NgModule providedIn: InjectorType<any> | "root" | "platform" | "any" | null; // 此定义所属的令牌 token: unknown; // 要执行以创建可注入实例的工厂方法 factory: (t?: Type<any>) => T; // 在没有显式注入器的情况下,存储可注入实例的位置 value: T | undefined; }
使用@Injectable()
的providedIn
时,优化工具可以进行 Tree-shaking 优化,从而删除应用程序中未使用的服务,以减小捆绑包尺寸。
本文简单介绍了在 Angular 依赖注入体系中比较关键的几个概念,主要包括Injector
、Provider
和Injectable
。
对于注入器、提供者和可注入服务,我们可以简单地这样理解:
注入器用于创建依赖,会维护一个容器来管理这些依赖,并尽可能地复用它们。
一个注入器中的依赖服务,只有一个实例。
注入器需要使用提供者来管理依赖,并通过 token(DI 令牌)来进行关联。
提供者用于高速注入器应该如何获取或创建依赖。
可注入服务类会根据元数据编译后,得到可注入对象,该对象可用于创建实例。
更多编程相关知识,请访问:编程入门!!
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!