同じレイヤーでのオニオンアーキテクチャの依存関係: インフラストラクチャとWebの通信 質問する

同じレイヤーでのオニオンアーキテクチャの依存関係: インフラストラクチャとWebの通信 質問する

私はASP.NET MVCアプリケーションを設計しています。オニオンアーキテクチャジェフリー・パレルモによって説明されました。

これは ASP.NET MVC 2.0 プロジェクトであり、専用のビュー モデルを使用してすべてのビューを厳密に型指定する必要があります。ドメイン モデルをビューに渡すことはありません。変換には AutoMapper を使用しています。AutoMapper はインフラストラクチャ内で分離されており、Web は AutoMapper が使用されていることを認識せず、気にも留めません。

現在、Web プロジェクトで IViewModelMapping インターフェイスを定義しています。これは、このサービスがコントローラーによって使用され、独自のビュー モデルに直接アクセスできるためです。この方法では、インターフェイスはドメイン モデル (コア内) とビュー モデル (Web 内) の両方にアクセスできます。

IViewModelMapping インターフェイスの実際の実装を提供するために、インフラストラクチャ プロジェクトに ObjectMapping 名前空間を作成しました。これにより、実際のマッピング実装がオニオンのインフラストラクチャに分離されます。これを行うには、インフラストラクチャがコアと Web の両方に依存する必要があります。

私の質問は、これらのプロジェクトは両方とも技術的にはタマネギの外側(同じレイヤー)にあるため、1 つのプロジェクトがそのレイヤー内の別のプロジェクトに依存することは許可されるのかということです。この設計に潜在的な落とし穴があることに気付いた人はいますか?

別の設計としては、IViewMapper インターフェイスを Core に移動する方法がありますが、Core は ViewModel クラスにアクセスできないため、これは不可能です。ビュー モデルを Core に移動することもできますが、それらは UI レイヤーに固有のものであるため、Core には属さないと思います。

提案されたアーキテクチャは次のとおりです。インフラストラクチャはコアと Web に依存していることに注意してください。Web は分離されたままで、コアのビジネス ロジックにのみアクセスできます。

http://www.matthidinger.com/images/onion-arch.png

ベストアンサー1

インフラストラクチャが UI (Web) に依存しないようにしたいというのは正しいのですが、私は時々そのルールを破ります。

IViewModelMapping の代わりに、メソッド Map() を持つ IMapper を作成することをお勧めします。そうすれば、インターフェイスは、ビュー モデル マッピング、または通常のマッピングに関係する実装を持つことができます。いずれにしても、そのインターフェイスは、意味的にどのタイプのモデルにもバインドされていないため、Core に配置できます。

素晴らしいグラフィックです。質問の核心に答えられたと思います。オニオン アーキテクチャの全体的な哲学は、ビジネス ロジックとモデルをアプリケーションの中央 (コア) に保持し、依存関係を可能な限り外側に押し出すことです。

おすすめ記事