Blog

ASP.NET Coreは依存性注入をサポートしています—実際、ASP.NETCoreはそれに大きく依存しています！しかし、依存性注入（DI）とは正確には何ですか？

ASP.NET Core は依存性注入をサポートしています—実際、ASP.NETCoreはそれに大きく依存しています！しかし、依存性注入（DI）とは正確には何ですか？

Microsoftのドキュメントでは、次のように定義されています。

「[a]ソフトウェアデザインパターン。これは、クラスとその依存関係の間で制御の反転（IoC）を実現するための手法です。」

なんて素晴らしく抽象的な！これを分解しましょう。 .NET開発者として、私たちはクラスが何であるかを知っています。また、「依存関係」とは何か、つまりクラスが動作するために依存する他のビット（クラス、インターフェイス、またはデータ）についても理解していると思います。

「制御の反転」はどうですか？ Microsoftのドキュメントには、依存性逆転を説明するための優れた図がいくつかありますが、それを説明するためのより簡単な方法があると思います。各クラスが依存するものの作成を管理する代わりに（多くの場合、C＃でnewkeywordを使用することにより）、他の何かが作成して各依存関係を提供することを期待して、その制御を放棄し、代わりに必要なものを要求します。

ASP.NET Coreの世界では、依存性注入とは通常、クラスの依存性がコンストラクターで提供されるコンストラクター注入を意味します。

簡単な例を見てみましょう。

パブリックインターフェイスIPet

{{

文字列名{取得; }

}

パブリッククラスの犬：IPet

{{

public Dog（string name）=> Name = name;

パブリック文字列名前{取得; }

}

パブリッククラスPetOwner

{{

public PetOwner（IPet pet）=>ペット=ペット;

public IPet Pet {get; }

}

// ...アプリケーションの後半

IPet dog = new Dog（ 'Poppy'）;

PetOwner sean = new PetOwner（dog）;

この例では、名前of the Dogは、 PetOwnerのPetの場合と同様に、コンストラクタ依存関係として提供されます。

これはコンストラクターによる依存性注入です！

これを行うことの利点は何ですか？

さて、「新しいのは接着剤」ということわざがあります。アプリケーションで新しいキーワードを使用するたびに、特定の実装に「接着」します。

サンプルコードのバリエーションを見てみましょう。

パブリッククラスPetOwner

{{

public PetOwner（）=> Pet = new Dog（ 'Poppy'）;

public IPet Pet {get; }

}

新しいものはPetOwnerクラス内にあります。つまり、すべてのPetOwnerです。インスタンスは「ポピー」という名前のペットに「接着」されます。それだけでなく、彼らも常に犬になります！たぶんそれは私のユースケースには問題ありません🐕‍🦺、しかしあなたはどうですか？

新しいキーワードをクラスの外に移動し、ペットを提供するPetOwnerのコンストラクター（最初に行った）を介して、あらゆる種類のIPetを任意のPetOwnerに提供できるようにします。これは私たちにとってはるかに役立つでしょう！

柔軟性の利点は、テスト容易性にも影響します。インターフェイスを介して依存関係を提供することにより、アプリケーションの実行時にデータベース、Webサービス、およびファイルシステムに接続するクラスに依存できます。同時に、いくつかのテストを実行したいときはいつでも、それらを偽のバージョンに置き換えても、インターフェースに準拠させることができます。

単体テストに関するMicrosoftのドキュメントで、テストにインターフェイスを使用する利点を参照してください。

コンテナに汚い仕事をさせてください

上記の例は、数行のC＃を使用して依存性注入を実行する方法を示しています。ただし、アプリケーションが成長し始めると、タイプの数（インターフェイスやクラスなど）の増加と、それらのタイプの相互依存性に気づきます。

この複雑さは維持するのが難しくなる可能性があります。また、依存関係があり、それぞれに独自の依存関係があるなどの理由で、使用するクラスを作成するのが難しくなる可能性があります。次に、実際に使用する1つのクラスに対してすべてを作成し、準備する必要があります。 ヤクシェービングについて話してください！

これらすべてのクラスの作成と管理も、特に依存関係の有効期間が異なる場合は、注意が必要になる可能性があります。

一部の依存関係はアプリケーションの存続期間（シングルトン）を持続する必要がありますが、他の依存関係は現在のHTTP要求と一致する存続期間（スコープ）を持ちます。残りは必要になるたびに作成され、参照されなくなると破棄されます（一時的）。

幸い、依存関係の管理に役立つ一般的なツールがあります。

依存性注入コンテナは、開発者が指示する特別に設計されたライブラリです。これらの手順は、アプリケーションですべてのタイプを作成する方法と、それらのタイプの有効期間をコンテナに指示します。

コンテナを使用することで、すべてのクラスとインターフェイスを登録し、コンテナに依存して、新しい必要なもののチェーンをたどるという汚い作業を行うことができます。これにより、最終的にクラスのインスタンスを取得できます。

開発者は、過去に新しいプロジェクトを開始するたびに、 多くのDIコンテナーのいずれかを選択し、そのコンテナーをアプリケーション用に構成する必要がありました。 ASP.NETも.NETFrameworkも、すぐに使用できるものを提供していませんでした。

ただし、ASP.NET Coreでは、多くの変更が加えられました。

ASP.NET Coreで依存性注入はどのように機能しますか？

ASP.NET Coreにより、依存性注入は、フレームワークが組み込みのDIコンテナーを提供する範囲で、ファーストクラスでサポートされる機能になりました。フレームワーク自体はこのコンテナーに依存しているため、内部フレームワークコードは依存性注入デザインパターンを使用できます。

開発者は、多くのオープンソースDIコンテナライブラリの1つを統合できます。各ライブラリには独自の特別な機能と利点があります。または、ユースケースで他の機能が必要ない場合は、組み込みのコンテナを使用できます。

依存関係の登録は、 StartupクラスのConfigureServices（）メソッドで実行されます。以下の例では、IUserServiceインターフェイスを実装するUserServiceを登録し、スコープ付き（リクエストごとに1つのインスタンス）の有効期間で登録します。

public void ConfigureServices（IServiceCollection services、IWebHostEnvironment env）

{{

services.AddScoped （）;

}

この1行で、IUserServiceのコンストラクターパラメーターを持つすべてのクラスでUserServiceのインスタンスを使用できるようになります。さらに、作成された各インスタンスが単一のリクエスト内のクラス間でのみ共有され、その最後にUserServiceが破棄されることが保証されます。

ASP.NETコアにKenticoエクスペリエンス13を統合

Kentico Xperience 13は、ASP.NET Core、および依存性注入に対するフレームワークのアプローチを完全にサポートしています。 Xperience13をASP.NETCoreプロジェクトに統合する場合は、ドキュメントを読むだけで、そのすべての種類とインターフェイスにアクセスする方法を確認できます。

重要なのは.AddKentico（）;の呼び出しです。Startup.ConfigureServices（）;の拡張メソッド方法。

public void ConfigureServices（IServiceCollection services、IWebHostEnvironment env）

{{

services.AddKentico（）;

//..。

}

とても簡単です！ KenticoXperienceがすべての作業を行います。正しいライフタイムとともに、すべてのプラットフォームのタイプを登録します。これは、追加の構成を行うことなく、クラスのコンストラクターのどこからでもIUserInfoProviderとIPageRetrieverの使用を開始できることを意味します。

もちろん、Kentico Xperience 13は、コンテンツツリーベースのルーティング、 ページビルダー、 柔軟なコンテンツ検索など、さらに多くの機能を提供します。したがって、Kentico Xperience13とASP.NETCoreで依存性注入をセットアップして使用し始めると、さらに多くのことを学び、探索することができます。

自分で調べたい場合は、無料トライアルをダウンロードしてください。