Heim > Artikel > Web-Frontend > Lassen Sie uns über die Grundkonzepte des Abhängigkeitsinjektionssystems von Angular sprechen
In diesem Artikel können Sie über Angular sprechen und das Grundkonzept der Abhängigkeitsinjektion vorstellen. Ich hoffe, dass es für alle hilfreich ist!
Als Front-End-Framework, das „für große Front-End-Projekte“ entwickelt wurde, verfügt Angular tatsächlich über viele Designs, die es wert sind, erwähnt und erlernt zu werden. Diese Serie wird hauptsächlich zum Studium der Implementierungsprinzipien dieser Designs und Funktionen verwendet. Dieser Artikel konzentriert sich auf das größte Merkmal von Angular – die Abhängigkeitsinjektion. Zunächst stellen wir einige grundlegende Konzepte im Angular-Abhängigkeitsinjektionssystem vor.
Da wir das Design der Abhängigkeitsinjektion des Angular-Frameworks vorstellen werden, legen wir zunächst den Grundstein für das Grundkonzept der Abhängigkeitsinjektion. Wir verwechseln oft die Konzepte Dependency Inversion Principle (DIP), Inversion of Control (IoC) und Dependency Injection (DI), daher stellen wir sie hier kurz vor. [Verwandte Tutorial-Empfehlungen: „angular Tutorial“]
Geringe Kopplung und hohe Kohäsion sind wahrscheinlich eines der Entwurfsziele jedes Systems, und aus diesem Grund gibt es Es gibt viele Entwurfsmuster und -konzepte, einschließlich der Entwurfsideen des Abhängigkeitsinversionsprinzips und der Kontrollinversion.
(1) Abhängigkeitsinversionsprinzip (DIP).
Die ursprüngliche Definition des Abhängigkeitsinversionsprinzips lautet:
Einfach ausgedrückt: Module sollten nicht direkt voneinander abhängen, sondern auf einer abstrakten Regel (Schnittstelle oder abstrakte Klasse) basieren.
(2) Umkehrung der Kontrolle (IoC).
Die Definition der Umkehrung der Kontrolle lautet: Die Abhängigkeiten zwischen Modulen werden von innerhalb des Programms nach außen instanziiert und verwaltet. Das heißt, wenn ein Objekt erstellt wird, wird es von einer externen Entität gesteuert, die alle Objekte im System steuert, und die Referenzen der Objekte, von denen es abhängt, werden an es übergeben (injiziert).
Es gibt zwei Hauptmethoden zur Implementierung der Umkehrung der Kontrolle:
(3) Abhängigkeitsinjektion.
Abhängigkeitsinjektion ist die häufigste Technik zur Umkehrung der Kontrolle.
Abhängigkeitsumkehr und Steuerungsumkehr ergänzen sich und können oft zusammen verwendet werden, um die Kopplung zwischen Modulen effektiv zu reduzieren.
In Angular wird auch die Abhängigkeitsinjektionstechnologie verwendet. Wenn eine Klasse instanziiert wird, stellt das DI-Framework ihr die von der Klasse deklarierten Abhängigkeiten zur Verfügung (Abhängigkeit: bezieht sich darauf, wann die Klasse einen Dienst oder ein Objekt benötigt). zur Erfüllung seiner Funktion erforderlich ist).
Abhängigkeitsinjektion in Angular dreht sich im Wesentlichen um Komponenten oder Module und wird hauptsächlich verwendet, um Abhängigkeiten für neu erstellte Komponenten bereitzustellen.
Der wichtigste Abhängigkeitsinjektionsmechanismus in Angular ist der Injektormechanismus:
Dabei handelt es sich hauptsächlich um zwei Konzepte, nämlich Injector-Injektor und Provider-Anbieter. Werfen wir einen Blick darauf.
Injector wird verwendet, um Abhängigkeiten zu erstellen, einen Container zum Verwalten dieser Abhängigkeiten zu verwalten und sie so weit wie möglich wiederzuverwenden. Der Injektor stellt einen Singleton der Abhängigkeit bereit und injiziert dieses Singleton-Objekt in mehrere Komponenten.
Als Container zum Erstellen, Verwalten und Verwalten von Abhängigkeiten ist die Funktion des Injektors offensichtlich einfach: Abhängigkeitsinstanzen erstellen, Abhängigkeitsinstanzen abrufen und Abhängigkeitsinstanzen verwalten. Wir können es auch aus dem Quellcode der abstrakten Klasse Injector
erkennen: 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;Das heißt, wir können die Abhängigkeitsinstanz, die gemeinsam genutzt werden muss, zum Injektor hinzufügen und diese abfragen und abrufen Injektor über Token abrufen. Es ist zu beachten, dass Injektoren in Angular hierarchisch sind. Daher ist das Finden von Abhängigkeiten auch ein Prozess, bei dem der Injektorbaum nach oben durchquert wird. 🎜🎜Das liegt daran, dass Anwendungen in Angular in Modulen organisiert sind. Weitere Informationen finden Sie unter 5. Modulare Organisation 🎜. Im Allgemeinen ist das DOM der Seite eine Baumstruktur mit
html
als Wurzelknoten. Auf dieser Grundlage befinden sich auch die Komponenten und Module in der Angular-Anwendung in einer begleitenden Baumstruktur. 🎜🎜Der Injektor bedient Komponenten und Module und ist außerdem in einer Baumstruktur von Modulen und Organisationen montiert. Daher ist Injector auch in Modul- und Komponentenebenen unterteilt, die spezifische Instanzen von Abhängigkeiten für Komponenten bzw. Module bereitstellen können. Injektoren sind vererbbar, was bedeutet, dass, wenn der angegebene Injektor eine Abhängigkeit nicht auflösen kann, er den übergeordneten Injektor auffordert, diese aufzulösen, wie wir auch aus dem obigen Code zum Erstellen des Injektors ersehen können: 🎜// 创建一个新的 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 令牌)来进行关联。
提供者用于高速注入器应该如何获取或创建依赖。
可注入服务类会根据元数据编译后,得到可注入对象,该对象可用于创建实例。
更多编程相关知识,请访问:编程入门!!
Das obige ist der detaillierte Inhalt vonLassen Sie uns über die Grundkonzepte des Abhängigkeitsinjektionssystems von Angular sprechen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!