3

新しいアプリケーションでは、タマネギのアーキテクチャに従うことを計画しています。

ソリューションの階層は次のとおりです

  • ドメイン-サービスとリポジトリのすべてのインターフェースが定義されている場所。
  • インフラストラクチャ-これは、すべてのデータアクセスが配置されるレイヤーです。これらのクラスは通常、ドメインで定義されたインターフェースを実装します。
  • Web-これはアプリケーションの私のプレゼンテーション部分です。同じレイヤー内に、ドメインで定義されたサービスを実装するための別のフォルダーがあります。

私の計画は、依存性の解決に依存性注入を使用することです。当初、私はDI関連のコードをインフラストラクチャに配置することを考えました。しかし、問題は、サービスをマップするときに循環参照につながることです。実際のサービスの実装は私のWebプロジェクトにあり、Webプロジェクトはすでにインフラストラクチャを参照しているためです。Onion Architecture（推移的な依存関係）の原則に違反しているため、具体的なサービスを別のレイヤーに移動することはできません。

どんなリードでも大歓迎です。

4

1 に答える 1

2

答えは、「DI関連コード」をどのように定義するかによって異なります。

DIを、関心の分離と緩い結合を促進する一連の原則とパターンとして定義する場合、これらのパターン（たとえば、コンストラクターインジェクションなど）は、アプリケーションのすべてのレイヤーに適用する必要があります。SOLIDの原則やその他のOOのベストプラクティスを適用するのと同じように。

DIとは、このコンテナに直接依存する特定のコンテナとコードを意味する場合、このコードはアプリケーションのエントリポイントにのみ存在する必要があります。あなたのシナリオでは、これはWebレイヤーです。または、これがコンソールアプリの場合は、「メイン」プロシージャにすることもできます。アプリケーションのこの部分は、CompositionRootと呼ばれます。

各クラスはコンストラクターを介して依存関係を必要とすることは容易に理解できますが、これにより、依存関係を持つクラスを作成する責任がサードパーティに押し付けられます。それはどこにあるべきですか？ほとんどの人はできるだけ早く作曲したいと思っているようですが、正解は次のとおりです。

アプリケーションのエントリポイントに可能な限り近づけます。

この場所は、アプリケーションのコンポジションルートと呼ばれ、次のように定義されます。

コンポジションルートは、モジュールが一緒にコンポジションされるアプリケーション内の（できれば）一意の場所です。

これは、すべてのアプリケーションコードがコンストラクタインジェクション（または他のインジェクションパターン）のみに依存しているが、構成されていないことを意味します。アプリケーションのエントリポイントでのみ、オブジェクトグラフ全体が最終的に作成されます。

于 2012-08-20T20:06:39.267 に答える