デザイン - 依存性地獄ソリューション?

私たちは、BLLとDALで構成されるモデルを持つMVCアーキテクチャを使用します。

私たちのシステムのための "モジュール"を開発し、私が実装している特定のモジュールは、同じ依存関係の多くを利用しています。あるクラスは特に20の依存関係を持っています。現在、デフォルトのコンストラクタはデフォルトの具象実装を作成しており、独自の依存関係(つまりテスト)を注入できるようにする2番目のコンストラクタも用意しています。

20のコンストラクタ引数はかなり厄介なコードのような感じです。 他の厄介なことは、共通の機能を追加し始めたときに、同じクラスのコードを何度も何度も繰り返しているすべてのクラスにコンストラクタコードとフィールドを追加する必要があることです。

IoCコンテナはこれに対する自然な解決策のようですが、問題はどれくらいですか? DAL依存関係とBLL依存関係は含めることができますか? "ヘルパー"や "サービス"の依存関係はどうですか?ある時点で、静的なクラスのようなクラスを参照する能力を持つ「名前空間」構造を作り直しているところで、私は実際に何を得ているのか疑問に思っています。

私はこれを考えて問題を抱えています。誰もエレガントなソリューションやアドバイスを持っていますか?

0
正接に関連しています:ここでは、クラスが取る依存関係の数を減らす別の質問のための答えです。 stackoverflow.com/questions/5601920/…
追加された 著者 Domenic,
"これで思考がうまくいかない"。このチュートリアルをチェックしてください: github.com/ninject/ninject/wiki
追加された 著者 Merlyn Morgan-Graham,

1 答え

あなたがIoCルート(私が推薦する)に行くなら、コンテナ内のすべての依存関係を含めるでしょう。

多くの層が深い層があるとしても、それらの依存関係を作成することについて心配する必要はないという利点があります。

例えば、ClassAはそのコンストラクタ内で4つの他のクラスを取り込み、それぞれが2つのクラスを取り込み、それぞれが少なくとも1つのDAL参照を取ります。

その場合、あなたのUIとなる可能性のある最上位のレイヤー(「コンポジションルート」)の IoC を参照し、「オブジェクトAのインスタンスを与えてください」と言うだけでいいですIoCは、オブジェクトグラフを構成するために必要な様々な依存関係について、他の20個のインスタンスを自動的にインスタンス化する。

あなたのクラスは、コンストラクタに貼り付けるだけのものが必要な場合、依存関係を作成する方法を心配する必要がなくなり、 IoC によって確実に取得されます。

また、 IoC を使用していても、あるクラスの20個の依存関係が明確なコードの匂いであるとコメントします。通常、クラスはあまりにも多くのことをしており、単一責任原則に違反していることを示しています。

7
追加された
+1 - IoCが明示的に(MVCの言い訳を言い訳する)ルートであり、あなたの用語を「自動的に」使用することに強く同意する。
追加された 著者 Reddog,
+1 SRPの違反の言及のために。間違いなくデザインを見て良いアイデア。
追加された 著者 Joshua Rodgers,