3

Dependency Inversion Principle に従い、流暢に構成された Dependency Injection (DI) コンテナーを利用する MVC 4 Web ソリューションを設計する方法を研究してきました (つまり、コンパイル時の型チェックを使用)。

ASP.NET MVC 4 依存性注入の多くの例は、MVC フレームワークが提供するエントリ ポイントに DI を実装するための詳細に焦点を当てていることがわかりました。結果として得られる階層化されたアプローチ (赤い矢印で示される依存関係) に引き寄せられここに画像の説明を入力 ます。残念ながら、これは、高レベルのモジュールが低レベルのモジュールに依存するという従来の依存関係モデルを繰り返します。依存性逆転の原則に従って、IService インターフェイスは WebProject に移動されます。残念ながら、これにより 2 つのプロジェクト間に循環参照が作成されます。循環参照 ここに画像の説明を入力 を回避するために、CompositionRoot は独自のプロジェクトに移動されます。 ここに画像の説明を入力

コンテナーをブートストラップする方法の問題が残っています (WebProject 内から直接参照することはできません)。

アセンブリが初期化を実行しているディレクトリを取得するための最良の方法の助けを借りて、リフレクションを使用して実現できます。

var assembly = System.Reflection.Assembly.LoadFile(Helper.AssemblyDirectory + "/DependencyInjectionProject.dll");
var type = assembly.GetType("DependencyInjectionProject.Bootstrapper");
IDependencyResolver resolver = (IDependencyResolver)type.GetMethod("Initialise").Invoke(null, null);
DependencyResolver.SetResolver(resolver);

ビルドを簡単にするために、DependencyInjectionProject のビルド ターゲットを WebProject の bin ディレクトリに設定しました。目的を達成しました。依存関係を反転し、コンパイル時にコンテナー構成をチェックしましたが、IIS Express で WebProject を実行するときにビルド ターゲットの競合が頻繁に発生するため、このアプローチには完全に満足していません。

これらの要件を満たすための他の経験やアプローチを聞くことに非常に興味があります。コンパイル時の構成をやめて、テキストベースの構成を採用する必要がありますか? 私が見ていない循環依存の落とし穴を回避するレイヤーの明らかな構造はありますか?

4

2 に答える 2

-1

IService を Web プロジェクトに移動したくないでしょう。循環参照 (これは必ずしも取り決めを破るわけではありませんが、VS では許可されませんが、他のいくつかの方法で実行できます) を除けば、設計が悪いだけです。

下位レベルのモジュールに依存する上位レベルのモジュールには、まったく問題はありません。これが問題だと思う理由がわかりません。依存関係の逆転は、実際にはモジュールまたはアセンブリの依存関係を参照するのではなく、インターフェイスの依存関係を参照します。(私はここで一般的に話していますが、具体的には interface キーワードについてではありません)。実際、個別のアセンブリがまったくなくても DI を持つことができます...すべてが同じアセンブリにある可能性があります。

ただし、実装を個別のアセンブリに分割することを選択した場合、特定の制限があります。これらは主に、アセンブリ システムの実装上の問題です。

モジュールの依存関係の問題は、2 つのモジュールだけでは実際には現れません。3つ以上あるとさらに大変です。

私はタマネギのアーキテクチャを自分で使用するのが好きです。このメソッドでは、インターフェイスと共通の型 (エンティティなど) を含む個別のアセンブリを作成します。このアセンブリには多くのコードが含まれているわけではなく、ほとんどが単なる定義です。

その上にデータ層とビジネス層があります。これらは、エンティティとインターフェイスの共通ア​​センブリに依存します。次に、ビジネスに依存する UI レイヤー (または、多くの場合、ビジネス レイヤーの単なるファサードであるサービス レイヤー) と共通レイヤーがあります。

このアプローチでは、UI は DAL と対話できず、その逆も同様です。ビジネス層は DAL および UI と通信します。そしてすべては、機能コードがほとんどなく、エンティティ、DTO、およびインターフェイスだけの共通インターフェイス アセンブリに依存しています。そのため、コモンはコア .NET のもの以外には何も依存しません。

    UI <--------> Service/Business <--------> DAL
     |                   |                     |
     +----------> Common (IService) <----------+

循環参照はなく、誰もが欲しいものを手に入れ、必要な人とだけ話します。

于 2013-05-24T04:15:48.327 に答える