Angular での依存関係注入パターンの深い理解 (プレイケース)

この記事では、Angular の依存関係注入モードを詳しく理解し、依存関係注入モードのアプリケーションとゲームプレイのケースを共有します。皆様のお役に立てれば幸いです。

#1 インジェクション、コンポーネント ツリー階層通信モードとデザイン パターン

1.1 コンポーネント通信モード

Angular プロジェクト開発では、通常、コンポーネントの通信に入力プロパティ バインディングと出力イベント バインディングを使用しますが、入力と出力は親コンポーネントと子コンポーネントの間でのみ情報を渡すことができます。コンポーネントは、呼び出し関係に基づいてコンポーネント ツリーを形成します。プロパティ バインディングとイベント バインディングのみがある場合、2 つの非直接関係コンポーネントは、各接続ポイント自体を通じて通信する必要があります。中間者は、実行するいくつかのことを継続的に処理し、渡す必要があります。知る必要はありません (図 1 左)。 Angular で提供される Injectable Service は、モジュール、コンポーネント、または命令で提供でき、コンストラクターでの注入と組み合わせることで、この問題を解決できます (図 1 の右)。 [関連チュートリアルの推奨事項: "

angular チュートリアル"]

図 1 コンポーネント通信モード

左側の図は情報を送信するだけです親子コンポーネントを介して、ノード a とノード b は多くのノードを介して通信する必要があります。ノード c が何らかの構成を通じてノード b を制御したい場合、それらの間のノードも追加の属性またはイベントを設定して、対応する情報を透過的に送信する必要があります。右図の依存性注入モードのノード c は、ノード a とノード b が通信するためのサービスを提供できます。ノード a はノード c が提供するサービスと直接通信し、ノード b もノード c が提供するサービスと直接通信します。最後に、通信が簡素化され、中間ノードはコンテンツのこの部分に結合されておらず、上位コンポーネントと下位コンポーネントの間で発生する通信を明確に認識しません。

1.2 依存関係の挿入を使用した制御の反転の実装

依存関係の挿入 (DI) は Angular に固有のものではなく、制御の反転 (IOC) を実装する手段です。 ) 設計パターン、依存関係注入の出現により、手動インスタンス化の過剰結合の問題が解決されます。すべてのリソースは、リソースを使用する 2 者によって管理されるのではなく、リソース センターまたはサード パーティによって提供され、多くの利点がもたらされます。 。まず、リソースの一元管理により、リソースが構成可能になり、管理が容易になります。第 2 に、リソースを使用する 2 つの当事者間の依存度 (いわゆるカップリング) が軽減されます。

現実の世界に喩えると、鉛筆などの製品を購入するとき、その種類の製品を購入するための店を見つけるだけで済み、鉛筆がどこで生産されたかは気にされません。木材と鉛筆の芯はどのように接着されているのか? 鉛筆の筆記機能を完成させるために必要なだけであり、特定の鉛筆メーカーや工場とは一切連絡をとりません。ストアに関しては、適切なチャネルから鉛筆を購入し、リソースの構成可能性を実現できます。

コーディング シナリオと組み合わせることで、より具体的には、ユーザーはインスタンスを挿入して使用するためにインスタンス (新しい操作) を明示的に作成する必要がなく、インスタンスの作成はプロバイダーによって決定されます。リソース管理はトークンを介して行われます。プロバイダーやインスタンスの作成は考慮されないため、ユーザーはいくつかのローカル注入メソッド (トークンの二次構成) を使用して、最終的にインスタンスの置換と依存関係注入モードを実現できます。アプリケーションとアスペクトのプログラミング ( AOP) は相互に補完します。

2 Angular での依存関係の注入

依存関係の注入は、Angular フレームワークの最も重要なコア モジュールの 1 つです。Angular はサービス タイプの注入だけでなく、独自のサービス タイプの注入も提供します。コンポーネントツリー インジェクションの依存関係ツリーであり、関数や値のインジェクションも可能です。つまり、Angular フレームワークでは、子コンポーネントは親コンポーネントのトークン (通常はクラス名) を介して親コンポーネントのインスタンスを注入できます。コンポーネントライブラリの開発では、パラメータのマウントや状態共有、さらには親コンポーネントが配置されているノードのDOMの取得など、親コンポーネントをインジェクトすることで対話や通信を実現するケースが非常に多いです。

2.1 依存関係の解決

Angular インジェクションを使用するには、まずそのインジェクション解決プロセスを理解する必要があります。 node_modules の解析プロセスと同様に、依存関係が見つからない場合、依存関係は常に親レイヤーにバブルアップして依存関係を見つけます。古いバージョンの Angular (

v6 より前) では、注入解析プロセスがマルチレベル モジュール インジェクター、マルチレベル コンポーネント インジェクター、および要素インジェクターに分割されています。新しいバージョン (v9 以降) は 2 レベルのモデルに簡素化されています。最初のクエリ チェーンは、静的 DOM レベルの要素インジェクター、コンポーネント インジェクターなど (総称して要素インジェクターと呼ばれます) であり、もう 1 つのクエリ チェーンはモジュールインジェクターです。解析の順序と解析失敗後のデフォルト値については、公式のコード コメント ドキュメント (provider_flag) でより明確に説明されています。

図 2 2 レベルのインジェクター検索依存関係プロセス (画像ソース )

つまり、コンポーネント/命令とコンポーネント/命令レベルの提供 挿入されたコンテンツは、まずコンポーネント ビュー内の要素内の依存関係をルート要素に至るまで検索します。見つからない場合は、要素が現在配置されているモジュール内で検索し、参照します (モジュールを含む)参照とルーティング遅延読み込み参照) が見つかるまでモジュールの親モジュール ルート モジュールとプラットフォーム モジュール。

ここでのインジェクターには継承があることに注意してください。要素インジェクターは、親要素のインジェクターの検索機能を作成および継承できます。モジュール インジェクターも同様です。継続的な継承の後は、js オブジェクトのプロトタイプ チェーンに似たものになります。

2.2 構成プロバイダー

依存関係解決の順序の優先順位を理解すると、適切なレベルでコンテンツを提供できます。これには、モジュール インジェクションと要素インジェクションの 2 つのタイプがあることはすでにわかっています。

• モジュール インジェクター: @NgModule のメタデータ属性でプロバイダーを構成でき、v6 以降に提供される @Injectable ステートメントを使用することもできます。provideIn はモジュール名 'root として宣言されます」など。 (実際には、ルート モジュールの上に、Platform と Null という 2 つのインジェクターがあります。ここでは説明しません。)

• 要素インジェクター: コンポーネントのメタデータ属性で @Component を設定できます。 Providers、viewProviders、またはディレクティブの @Directive メタデータ内のプロバイダー。

さらに、実際には、宣言モジュール インジェクターの使用に加えて、@Injectable デコレーターを次のように宣言することもできます。要素インジェクター。多くの場合、シングルトンを実装するためにルートで提供されるように宣言されます。モジュールやコンポーネントがプロバイダーを直接明示的に宣言することを避けるために、クラス自体を通じてメタデータを統合します。この方法では、クラスにコンポーネント ディレクティブ サービスやそれを挿入する他のクラスがない場合、型宣言にリンクされたコードは存在せず、これはコンパイラによって無視されるため、ツリーをシェイクすることができます。

これを提供する別の方法は、InjectionToken を宣言するときに値を直接与えることです。

これらのメソッドの短縮テンプレートは次のとおりです:

@NgModule({  providers: [
    // 模块注入器
  ]
})
export class MyModule {}

@Component({  providers: [
    // 元素注入器 - 组件
  ]，  
  viewProviders: [
      // 元素注入器- 组件视图
  ]
})
export class MyComponent {}

@Directive({  providers: [
   // 元素注入器 - 指令
 ]
})
export class MyDirective {}

@Injectable({
 providedIn: 'root'
})
export class MyService {}

export const MY_INJECT_TOKEN = new InjectionToken<myclass>('my-inject-token', {
 providedIn: 'root',
 factory: () => {
    return new MyClass();
 }
});</myclass>

依存関係の場所を指定するオプションが異なるといくつかの違いが生じ、最終的にはパッケージのサイズと注入できる依存関係に影響します。そして依存関係のライフサイクル。シングルトン (ルート)、サービス分離 (モジュール)、複数の編集ウィンドウ (コンポーネント) など、さまざまなシナリオに適用できるさまざまなソリューションがあります。不適切な情報の共有や冗長なコードのパッケージ化を避けるために、適切な場所を選択する必要があります。

2.3 さまざまなバリュー関数ツール

インスタンスインジェクションだけを提供すると、Angular フレームワークの依存関係インジェクションの柔軟性が発揮されません。 Angular は多くの柔軟な注入ツールを提供します。useClass は新しいインスタンスを自動的に作成し、useValue は静的な値を使用し、useExisting は既存のインスタンスを再利用でき、useFactory は指定された deps と指定されたコンストラクター パラメーターを使用して関数を通じて構築されます。これらの組み合わせは非常に多用途です。クラスのトークン トークンを切り取って、準備した別のインスタンスに置き換えることができます。トークンを作成して最初に値またはインスタンスを保存し、後で使用する必要があるときに再度置き換えることもできます。インスタンスのローカル情報は別のオブジェクトまたは属性値にマッピングされます。ここでのゲームプレイについては、次のケースを通じて説明しますので、ここでは説明しません。公式サイトにも参考になる作例が多数掲載されています。

2.4 インジェクションの消費とデコレーター

Angular でのインジェクションはコンストラクターでインジェクションすることも、get メソッドを通じて既存のインジェクターを取得することもできます。要素を挿入する。

Angular は、注入時にマークするデコレータの追加をサポートしています。バブリングを制限する

• @Host() 要素自体に制限する
• @Self()
#@SkipSelf() 要素自体に制限します
• @Optional() オプションとしてマークします
• @Inject() カスタム トークン token に制限します

こちらの記事「

@Self or @Optional @Host? Angular DI デコレータのビジュアル ガイド.」では、親コンポーネントと子コンポーネントの間で異なるデコレータが使用された場合に何が起こるかを非常に鮮明に示しています。ヒットインスタンス間の違い。

#図 3 さまざまなインジェクション デコレータのフィルタリング結果

2.4.1 補足: ホスト ビューと @Host

これらのデコレータの中で、@Host が最も理解するのが難しいかもしれません。ここでは、@Host に関する具体的な手順をいくつか示します。 @Host デコレーターの公式の説明は、

...ホスト要素に到達するまで任意のインジェクターから依存関係を取得します。

ここでの Host はホストを意味します。@Host デコレータはクエリの範囲をホスト要素内に制限します。ホスト要素とは何ですか?コンポーネント B がコンポーネント A のテンプレートで使用されるコンポーネントの場合、コンポーネント A のインスタンスはコンポーネント B のインスタンスのホスト要素です。コンポーネント テンプレートによって生成されるコンテンツはビューと呼ばれます。同じビューでも、コンポーネントが異なれば異なるビューになる場合があります。コンポーネント A が独自のテンプレート スコープ内でコンポーネント B を使用する場合 (図 4 を参照)、A のテンプレート コンテンツによって形成されるビュー (赤いボックスの部分) がコンポーネント A の埋め込みビューであり、コンポーネント B はこのビュー内にあるため、B については、このビューは B のホスト ビューです。デコレータ @Host は検索範囲をホスト ビューに制限します。見つからない場合はバブルアップされません。

図 4 埋め込みビューとホスト ビュー

3 ケースとゲームプレイ

以下では、実際のビューを使用してみましょう依存関係注入がどのように機能するか、エラーのトラブルシューティング方法、およびプレイ方法を確認するためのケースです。

3.1 ケース 1: モーダル ウィンドウは動的コンポーネントを作成しますが、コンポーネントが見つかりません

DevUI コンポーネント ライブラリのモーダル ウィンドウ コンポーネントはサービス ModalService を提供します。モーダル ボックスがポップアップし、カスタム コンポーネントとして構成できます。ビジネスの学生は、このコンポーネントの使用時に、パッケージがカスタム コンポーネントを見つけられないというエラーを報告することがよくあります。

たとえば、次のエラー レポート:

図 5 ModalService を使用する場合、EditorX を参照するコンポーネントを作成するエラー レポートでは、対応するサービスが見つかりませんProvider

ModalService がカスタム コンポーネントを作成する方法を分析します。 ModalService ソース コード 関数を開きます 52 行目と 95 行目。 componentFactoryResolver が渡されない場合、ModalService によって挿入された componentFactoryResolver が使用されることがわかります。ほとんどの場合、企業はルート モジュールに DevUIModule を一度導入しますが、現在のモジュールには ModalModule を導入しません。つまり図6の現状はこんな感じです。図 6 によると、ModalService のインジェクターには EditorXModuleService がありません。

図 6 モジュール サービス提供関係図

インジェクターの継承に従って、4 つの解決策があります。

• ModalModule が宣言されている場所に EditorXModule を配置し、インジェクターが EditorXModule によって提供される EditorModuleService を見つけられるようにします - これは最悪の解決策です。loadChildren 自体によって実装された遅延読み込みは、ホームページ モジュールの読み込みを減らすことであり、その結果はサブページ 使用する必要のあるコンテンツは AppModule に配置されますが、大きなリッチ テキスト モジュールは初回ロードで読み込まれるため、FMP (First Meaningful Paint) を悪化させるため採用できません。

• EditorXModule を導入し、ModalService を使用するモジュールに ModalService を導入することをお勧めします。推奨できない状況が 1 つだけあります。それは、別のトップレベルのパブリック サービスである ModalService を呼び出すことにより、ロードのために不要なモジュールが依然として上位層に配置されるということです。

• ModalService を使用するコンポーネントをトリガーするときは、現在のモジュールの componentFactoryResolver を挿入し、それを ModalService の open 関数パラメーターに渡します。これを使用することをお勧めします。 EditorXModule の紹介です。

• 使用するモジュールで、ModalService を手動で提供します。挿入された検索の問題を解決することをお勧めします。

4 つのメソッドは、実際には、ModalService によって使用されるインジェクターの内部チェーン内の EditorXModuleService の問題を解決しています。検索チェーンが 2 つのレベルにあることを確認することで、この問題は解決できます。

ナレッジポイントの要約

: モジュールインジェクターの継承と検索範囲。

3.2 ケース 2: CdkVirtualScrollFor が CdkVirtualScrollViewport を見つけられない

通常、複数の場所で同じテンプレートを使用する場合、テンプレートを通じて共通部分を抽出します。コンポーネント 開発中、開発者は共有部分を抽出したいと考え、エラーを報告しました。

#図 7 コードの移動と挿入エラーが見つからない

これは、CdkVirtualScrollFor 命令が CdkVirtualScrollViewport を注入する必要があるためです。ただし、要素注入のインジェクター継承システムは静的な AST 関係の DOM を継承しており、動的なものは不可能です。そのため、次のクエリ動作が発生し、検索が失敗します。

図 8 要素インジェクターのクエリ チェーンの検索範囲

最終解決策: 1) 元のコードの位置を変更しない、または 2) コード全体を変更する必要があります。テンプレートに埋め込まれていることがわかります。

図 9 CdkVitualScrollFo が CdkVirtualScrollViewport を見つけられるようにモジュール全体を埋め込む (解決策 2)

ナレッジ ポイントの概要: 要素の挿入コントローラーのクエリ チェーンは、静的テンプレートの DOM 要素の祖先です。

3.3 ケース 3: フォーム検証コンポーネントがサブコンポーネントにカプセル化されているため検証できない

このケースは、このブログ「Angular: Nested」から引用されています。テンプレート駆動型フォーム》。

フォーム検証を使用するときにも同じ問題が発生しました。図 10 に示すように、いくつかの理由から、3 つのフィールドのアドレスをコンポーネントにカプセル化して再利用します。

図 10 フォームの 3 つのアドレス フィールドをサブコンポーネントにカプセル化する

この時点で、エラーが報告されていることがわかります。 ngModelGroup ホスト内の ControlContainer が必要です。これは、ngForm ディレクティブによって提供されるコンテンツです。

図 11 ngModelGroup が ControlContainer を見つけられない

ngModelGroup コードを見ると、ホスト デコレータの制限が追加されているだけであることがわかります。

図 12 ng_model_group.ts は、挿入された ControlContainer の範囲を制限します

ここでは、viewProvider と usingExisting を使用して、AddressComponent のホスト ビューに ControlContainer プロバイダーを追加できます。

図 13 viewProvider を使用して、ネストされたコンポーネントに外部プロバイダーを提供する

ナレッジ ポイントの概要: viewProvider と usingExisting の素晴らしい組み合わせ。

#3.4 ケース 4: ドラッグ アンド ドロップ モジュールによって提供されるサービスは、遅延読み込みによりシングルトンではなくなり、その結果、相互にドラッグ アンド ドロップができなくなります# #社内ビジネス プラットフォームには国境を越えたものが含まれます。複数のモジュールのドラッグには、loadChildren の遅延読み込みが含まれます。各モジュールは、DragDropService を提供する DevUI コンポーネント ライブラリの DragDropModule を個別にパッケージ化します。ドラッグ アンド ドロップ命令は、Draggable 命令と Droppable 命令に分かれており、2 つの命令は DragDropService を通じて通信します。本来は同じモジュールを導入し、そのモジュールが提供するServiceを利用することで通信可能でしたが、遅延読み込み後、DragDropModuleモジュールが2重にパッケージ化され、インスタンスも2つ分離されてしまいました。現時点では、DragDropService が同じインスタンスではないため、遅延ロード モジュールの Draggable 命令は、別の遅延ロード モジュールの Droppable 命令と通信できません。

図 14 モジュールの遅延読み込みにより、サービスが同じインスタンス/単一ケースではなくなる

このステートメントにはシングルトンが必要であることは明らかです。シングルトンアプローチ 通常は

providerIn: 'root'

で十分ですが、コンポーネント ライブラリの DragDropService をモジュール レベルで提供し、ルート ドメインを直接提供しないのはなぜでしょうか。しかし、よく考えてみると、ここには別の問題もあります。コンポーネント ライブラリ自体は、さまざまな企業が使用するために提供されているため、ページ上の 2 か所に対応する 2 つのドラッグ アンド ドロップ グループがある企業では、リンクを希望しません。このとき、シングルトンはモジュールに基づく自然な分離を破壊します。 そうなると、ビジネス側でシングルトンの置き換えを実装する方が合理的になります。前に説明した依存関係クエリ チェーンを思い出してください。最初に要素インジェクターが検索され、見つからない場合はモジュール インジェクターが開始されます。したがって、代替のアイデアは、要素レベルのプロバイダーを提供できるということです。

図 15 拡張メソッドを使用して新しい DragDropService を取得し、ルート レベルで提供されるものとしてマークを付けます

図 16 同じセレクターを使用して、繰り返しの命令を重ね合わせたり、コンポーネント ライブラリの Draggable 命令と Droppable 命令に追加の命令を重ね合わせたり、DragDropService のトークンをルートにシングルトンを提供した DragDropGlobalService に置き換えたりすることができます

たとえば、図 15 と 16 では、要素インジェクターを使用して命令を重ね合わせ、DragDropService トークンを独自のグローバル シングルトンのインスタンスに置き換えます。現時点では、グローバル シングルトン DragDropService を使用する必要があるため、これら 2 つの追加命令を宣言してエクスポートするモジュールを導入するだけで、コンポーネント ライブラリの Draggable 命令 Droppable 命令が遅延読み込みモジュール間で通信できるようになります。

知識ポイントのまとめ: 要素インジェクターはモジュール インジェクターよりも優先されます。

3.5 ケース 5: ローカル テーマ関数のシナリオでローカルの問題にドロップダウン メニューをアタッチする方法

DevUI コンポーネント ライブラリのテーマは CSS カスタムを使用します属性 (css 変数) は、テーマの切り替えを実現するための root の CSS 変数値を宣言します。 1 つのインターフェイスで異なるテーマのプレビューを同時に表示したい場合は、DOM 要素でローカルに css 変数を再宣言して、ローカル テーマの機能を実現できます。以前テーマ ディザ ジェネレーターを作成していたとき、この方法を使用してテーマをローカルに適用しました。

図 17 部分的なテーマ関数

しかし、CSS 変数値をローカルに適用するだけでは十分ではありません。はデフォルトでボディの末尾にアタッチされます。つまり、そのアタッチ層がローカル変数の外側にあるため、非常に厄介な問題が発生します。ローカル テーマ コンポーネントのドロップダウン ボックスには、外部テーマのスタイルが表示されます。

図 18 ローカル テーマの外部コンポーネントにアタッチされているオーバーレイ ドロップダウン ボックスのテーマが正しくありません

この場合はどうすればよいですか?アタッチメント ポイントをローカル テーマ dom 内に戻す必要があります。

DevUI コンポーネント ライブラリの DatePickerPro コンポーネントのオーバーレイは、Angular CDK のオーバーレイを使用していることが知られています。一連の分析の後、次のようにインジェクションに置き換えました:

1)まず、OverlayContainer を継承し、独自の ElementOverlayContainer を実装します。以下に示します。

図 19 ElementOverlayContainer のカスタマイズと _createContainer ロジックの置き換え

2) 次に、プレビューのコンポーネント側に新しい ElementOverlayContainer を直接提供し、新しいオーバーレイを提供します。新しいオーバーレイが OverlayContainer を使用できることを確認します。本来、Overlay と OverlayContainer はルート上に提供されていますが、ここではこの 2 つをカバーする必要があります。

##図 20 OverlayContainer をカスタム ElementOverlayContainer に置き換え、新しい Overlay を提供します

この時点で、Web サイトとポップの DOM をプレビューします。上のレイヤーは、component-preview 要素に正常にアタッチされます。

図 21 cdk のオーバーレイ コンテナーが指定された dom にアタッチされ、部分的なテーマのプレビューが成功します。

また、内部にはカスタムの OverlayContainerRef もあります。 DevUI コンポーネント ライブラリ 一部のコンポーネントとモーダル ボックス ドロワー ベンチも、それに応じて置き換える必要があります。最後に、ポップアップ レイヤーとその他のポップアップ レイヤーを実現して、ローカル テーマを完全にサポートできます。

知識ポイントの要約: 優れた抽象パターンにより、モジュールを置き換え可能にし、エレガントなアスペクト プログラミングを実現できます。

#3.6 ケース 6: CdkOverlay ではスクロール バーに CdkScrollable 命令を追加する必要がありますが、エントリ コンポーネントの最外層には追加できません。

#最後の項目に到達しましたケーススタディとして、誰もがプロバイダーの本質を理解できるように、あまり形式的でないアプローチについて話したいと思います。プロバイダーを構成することは、本質的に、プロバイダーをインスタンス化または既存のプロバイダーへのマッピングを支援できるようにすることです。実例。 cdkOverlay が使用されている場合、ポップアップ ボックスをスクロール バーに追従させ、正しい位置で停止させたい場合は、スクロール バーに cdkScrollable 命令を追加する必要があることがわかりました。

これも前の例と同じシーンです。ページ全体はルーティングを通じて読み込まれます。簡単にするために、コンポーネントのホストにスクロール バーを書きました。

図 22 コンテンツ オーバーフロー スクロール バーは、component:host に overflow:auto を書き込みます

このようにして、より困難な問題に遭遇します。はルーター定義によって指定されます。つまり、

はどこにも明示的に呼び出されません。では、cdkScrollable 命令はどうなるでしょうか。追加してみたらどうでしょうか？解決策は、コードの一部をここに隠し、コアコードのみを残すことです。

図 23 インジェクションによってインスタンスを作成し、ライフ サイクルを手動で呼び出す

ここでは、cdkScrollable のインスタンスがインジェクションによって生成され、ライフ サイクルはコンポーネントのライフ サイクル ステージ中に同期的に呼び出されます。

この解決策は正式な方法ではありませんが、問題は解決します。読者が試してみるためのアイデアと探求としてここに残しておきます。

ナレッジポイントの概要: 依存関係注入構成プロバイダーはインスタンスを作成できますが、インスタンスは通常の Service クラスとして扱われ、完全なライフサイクルを持つことができないことに注意してください。

3.7 その他のプレイ方法: 代替プラットフォームをカスタマイズして、ターミナル上で実行されている Angular フレームワークの対話を実現します。

次のブログ投稿を参照してください。「##」 #ターミナルでの Angular アプリケーションのレンダリング>>

#図 24 RendererFactory2 レンダラとその他のコンテンツを置き換えて、Angular をターミナル上で実行できるようにします

作成者は、 RendererFactory2 など Renderer を使用すると、Angular アプリケーションを端末上で実行できます。これが Angular 設計の柔軟性であり、プラットフォームさえも交換可能であり、強力かつ柔軟です。交換の詳細については元の記事を参照してください。ここでは詳しく説明しません。

ナレッジ ポイントの概要

: 依存関係の挿入の力は、プロバイダーが独自に構成して、最終的に置換ロジックを実装できることです。

4 概要

この記事では、制御反転の依存関係注入モードとその利点を紹介し、Angular での依存関係注入が依存関係を見つける方法とプロバイダーの構成方法も紹介します。限定されたフィルタリング デコレータを使用して目的のインスタンスを取得する方法、および開発およびプログラミングで遭遇する問題を解決するために依存関係注入のナレッジ ポイントを組み合わせる方法を N ケースを通じてさらに分析する方法。

依存関係の検索プロセスを正しく理解すると、正確な場所でプロバイダーを構成したり (ケース 1 と 2)、他のインスタンスをシングルトンとして置き換えたり (ケース 4 と 5)、さらにはクロスネストすることができます。コンポーネント パッケージの制約が提供されたインスタンスに接続されるか (ケース 3)、提供されたメソッド カーブが命令のインスタンス化を実装するために使用されます (ケース 6)。

ケース 5 は単純な置き換えのように見えますが、置き換え可能なコード構造を作成できるようにするには、注入モードを深く理解し、各関数をより適切かつ合理的に抽象化する必要があります。この場合、依存性注入の効果を最大限に発揮できなくなります。インジェクション モードでは、モジュールがプラグ可能、プラグイン、およびパーツベースになるためのより多くのスペースが提供され、結合が減少し、柔軟性が向上するため、モジュールがよりエレガントかつ調和して連携できるようになります。

依存関係注入機能は強力です。コンポーネントの通信パスを最適化することに加えて、さらに重要なことに、制御の反転を実現し、カプセル化されたコンポーネントをプログラミングのより多くの側面やビジネス固有のロジックの実装に公開することもできます。柔軟になることもできます。

プログラミング関連の知識について詳しくは、

プログラミング ビデオ

をご覧ください。 ！

以上がAngular での依存関係注入パターンの深い理解 (プレイケース)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。