38

JeffreyPalermoによって記述されたOnionArchitectureを使用してASP.NETMVCアプリケーションを設計しています。

これはASP.NETMVC2.0プロジェクトであり、専用のビューモデルを使用してすべてのビューを厳密に入力する必要があります。ドメインモデルをビューに渡すことはありません。AutoMapperを使用して翻訳を行っています。AutoMapperはインフラストラクチャで分離されており、WebはAutoMapperが使用されていることを認識または認識していません。

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

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

私の質問は、これらのプロジェクトは両方とも技術的にはタマネギの郊外（同じレイヤー内）にあるため、1つのプロジェクトがそのレイヤー内の別のプロジェクトに依存することを許可されていますか？このデザインの潜在的な落とし穴に気付いた人はいますか？

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

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

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

4

3 に答える 3

28

インフラストラクチャがUI（Web）に依存することを望まないのは正しいですが、私は時々そのルールを破ります。

IViewModelMappingの代わりに、Map（）メソッドを使用してIMapperを作成すると思います。次に、インターフェイスには、ビューモデルのマッピング、または通常のマッピングに関係する可能性のある実装を含めることができます。いずれにせよ、そのインターフェースは、どのタイプのモデルにも意味的にバインドされていないため、Coreに含めることができます。

素晴らしいグラフィック。私はあなたの質問の要点に答えたことを望みます。Onion Architectureの全体的な哲学は、ビジネスロジックとモデルをアプリケーションの中央（コア）に保持し、依存関係を可能な限り外側にプッシュすることです。

于 2010-02-25T22:05:49.687 に答える
0

オブジェクトマッピングをWebレイヤーに移動してみてください。

于 2014-05-28T07:47:41.413 に答える
0

Web/UIレイヤーはインフラストラクチャレイヤーに依存できます。しかし、Webをインフラストラクチャ層に依存させるのは良い設計ではありません。オニオンアーキテクチャは、依存関係を可能な限り外側にプッシュすると言います。

UIで「\Builder」フォルダを作成できます。その中に1つのインターフェイスファイルを追加します。例..IBuilderまたはIMapperを使用して、ConvertToViewModelやCreateMappingなどのメソッドを宣言します。君が好きなものならなんでも。

* Builder**IBuilder.cs-ここでメソッドを宣言します。** Builder.cs ---ここでメソッドを実装し、ViewModelとそれに対応するDomainModel（コアレイヤーからの参照）の間のマッピングを定義し、ここで適切なViewModelを返します。

于 2016-09-25T03:12:34.037 に答える