0

現在、C#/.Net/MVC アプリケーションで DI を処理するために Ninject を使用しています。サービスのインスタンスの作成を追跡すると、ライフサイクル中にサービスがかなり頻繁に呼び出されて構築されることがわかります。そのため、サービスをインスタンス化してキャッシュし、キャッシュされたサービスをチェックしてから別のサービスをインスタンス化する必要があります。コンストラクターは非常に重い場合があります)。

サービスは一意のコンストラクター引数を必要としないため、これはばかげているように思えます。そのため、一度インスタンス化するだけで、アプリケーション スコープ全体で十分です。

私が簡単な代替手段として行ったこと（今のところ概念実証のために、それが機能するかどうかを確認するためだけです）は...

  • すべてのサービス インターフェイスをプロパティとして持つ静的クラス (AppServices と呼ばれる) を作成しました。
  • このクラスに、サービス ライブラリから各サービス インターフェイスの直接実装をインスタンス化する Init() メソッドを指定します。これは、Ninject (または他の DI ハンドラー) を使用していた場合に、それらをカーネルにバインドすることを模倣しています。

例えば

public static class AppServices(){
  public IMyService MyService;
  public IMyOtherService MyOtherService;

  public Init(){
     MyService = new MyLib.MyService();
     MyOtherService =  new MyLib.MyOtherService();
  }
}
  • App_Start で、Init() メソッドを呼び出して、一度だけインスタンス化される、グローバルにアクセス可能なサービスのリストを作成します。
  • それ以降、サービスのインスタンスが必要になるたびに、AppServices から取得しています。このようにして、必要のない新しいインスタンスを作成し続ける必要がなくなります。

例えば

var IMyService _myService = AppServices.MyService;

これは正常に機能し、まだ問題が発生したことはありません。私の問題は、これが単純すぎるように見えることです。アプリケーション スコープで静的クラスを作成するのは、ほんの数行のコードです。Ninjectが必要とすることを正確に実行しますが、(私の目的では私には思われる)はるかにクリーンでパフォーマンスを節約する方法で、なぜNinjectが必要なのですか? つまり、これらの複雑な依存性注入ハンドラーが作成されるのには理由がありますよね? 私の「単純な」DI の解釈には何か問題があるに違いありません。

サービス インスタンス用にグローバルな静的コンテナーを作成することがなぜ悪い考えなのか、誰でも教えてもらえますか? また、Ninject (または他の DI ハンドラー) が必要な理由を正確に説明できますか? 私は DI の概念を理解しているので、DI の優れた点を説明しようとしないでください。知っている。私の App_Start メソッドとは大きく異なる内部での動作を正確に知りたいです。

ありがとう

4

1 に答える 1