Clever Geek Handbook

Pure.DIの次のステップ

最近この投稿で、Pure.DIライブラリを紹介しました。NET 5コードアナライザー/ジェネレーターパッケージは、依存関係グラフを作成するためのヒントを使用して、純粋なDIスタイルでオブジェクトを作成するための単純なコードを作成するヘルパーとして考案されました。変更を監視し、タイプとそれらの間の依存関係を分析し、問題を強調し、解決策を提案します。Pure.DIライブラリは依存性注入コンテナではないことに注意することが重要です。そのタスクには次のものが含まれます。





  • 依存関係グラフ分析





  • 問題の定義とそれらを解決する方法





  • オブジェクトコンポジションのための効率的なコードの作成





前回の投稿での議論から、以下の問題に取り組む必要があるという印象を受けました。





  • ASP.NETフレームワークでPure.DIを使用する機能を追加します





  • Pure.DI.ContractsパッケージからAPIへのバイナリ依存関係を削除します





  • 操作Resolve()



    が複数回実行される場合のパフォーマンスを向上させる





現在、マイナーな改善の後、コードアナライザーは、ASP.NETプロジェクトがプロジェクトであるかどうかを自動的に検出し、ASP.NETとの統合を提供するカスタム拡張メソッドコードを生成します。この機能を実証するために、Blazorサーバーアプリケーションを選択しました。





:





DI.Setup()
  .Bind<IDispatcher>().As(Singleton).To<Dispatcher>()
  .Bind<IClockViewModel>().To<ClockViewModel>()
  .Bind<ITimer>().As(Scoped).To(_ => new Timer(TimeSpan.FromSeconds(1)))
  .Bind<IClock>().As(ContainerSingleton).To<SystemClock>();

DI   ASP.NET :





services.AddClockDomain();

, -, . , :





  • ContainerSingleton - ASP.NET





  • Scoped - ASP.NET scope





ASP.NET, .





API “” Pure.DI.Contracts. API “ ” , API . , , analyzers Pure.DI . , , , “ - ”.





ASP.NET Frameworkは、Resolve()



すべての要求に対してメソッドを呼び出します。この呼び出しのオーバーヘッドを削減するために、オブジェクトコンポジションのルート要素タイプをそのコンポジションの作成メソッドにマッピングするコードが最適化されています。比較テストの結果はここにあります。この比較では、パフォーマンスメトリックを取得するために物議を醸す方法を使用していることを強調したいと思います。したがって、これらの結果は、複数のメソッド呼び出しのオーバーヘッドの概算を示しますResolve()



。





いつものように、建設的なコメントやアイデアは大歓迎です。







More articles:


All Articles