4

ロガー、セキュリティ、構成などのインフラストラクチャ アイテムでは、これらを必要とするすべてのクラスに実際に注入するか、サービス ロケーターに注入してから、クラスがサービス ロケーターを使用して依存関係 (またはいくつかの依存関係) を解決できるようにする必要があります。他のメカニズム）？

すべてのクラスが 10 個のパラメーター ctor を持ち、DI を介して依存関係を満たすため、本当にばかげているように見えます。そのコードの匂いIMO。リポジトリやサービス プロキシ/コネクタなどは理解できますが、ログは理解できません。

4

3 に答える 3

4

いくつかのオプションがあります。

  1. プロパティ注入を使用し、ctor でデフォルトを設定します。例えば

    class foo 
{
    public ILogger Logger {get;set;}

    public foo()
    {
       Logger = NullLogger.Instance;
    }
}
  2. AOP タイプのアプローチを使用します。動的プロキシを使用すると、パブリック呼び出しをログ ステートメントでラップできますが、ログが実際にコンポーネント自体に挿入されることはありません。Castle.DynamicProxyこのアプローチの詳細については、.Net 属性を参照またはカスタムしてください。

では、なぜこれほど多くのインフラストラクチャの問題がコンポーネントに注入されているのかという疑問があります。あなたが説明することは分野横断的な懸念と見なされ、通常、これは AOP (アスペクト指向プログラミング) の一部を通じて処理されるため、コア システムに多くの重複はありません。

于 2012-06-01T16:26:11.660 に答える
2

それはすべて、インフラストラクチャと残りのコードの間の線をどこに引くかによって異なります。データベース接続をインフラストラクチャと見なしますか? 私はしません。

プロパティの注入は、依存関係を隠し、コンストラクターが完了したときにクラスが適切に初期化されないため、コードの臭いです。循環依存関係を解決するためにのみ使用してください。

ロギングの非常に特殊なケースでは、シングルトンを使用してロガーを取得します。

通常、AOP については同意しますが、私はランタイム AOP フレームワークのファンではなく、チームは AOP の概念を理解していません。IOC の概念をほとんど理解していない

私のIOC の紹介が役に立つかもしれません。

于 2012-06-04T14:09:40.960 に答える
1

ロギングについて - NLog (またはお気に入りのロガー) を使用するだけで完了です。本当に奇妙なシナリオでない限り、ロガーを抽象化および/または注入する理由はありません。

構成に関して - 少数のクラスのみが構成のコンシューマーになる必要があるため、これによりコンストラクターが肥大化することはありません。構成と DI の適切な議論については、この質問も参照してください。

セキュリティについて - 繰り返しますが、セキュリティ依存関係の消費者になるべきクラスはごくわずかだと思います。多くのクラスがセキュリティに関係している場合は、設計を見直す必要があるかもしれません。

一般に、クラスにコンストラクター パラメーターが多すぎる場合は、依存関係がインフラストラクチャーであるかどうかに関係なく、実行しすぎている可能性があります。

于 2012-06-01T19:18:47.943 に答える