3

以前は MVC デザイン パターンを扱ったことがありませんでしたが、最近、ASP.NET MVC を使用してプロジェクトに取り組み始めました。

データ層として ActiveRecord を使用しています。

また、ビュー モデル (ビューごとに固有) と AutoMapper を使用して、ビュー モデルを EntityFramework エンティティにマップしています。

MVC、EntityFramework について調査し、さまざまな記事を読んで数日で、次の設計を思いつきました。

私のソリューションには、ビューとコントローラーを含む Web プロジェクト (プレゼンテーション レイヤー) があります。

ViewModels と Services (すべてのビジネス ロジックが行くビジネス レイヤー) を定義するコア プロジェクトがあります。

すべてのEFエンティティが存在するEntityModelsプロジェクトがあります(データレイヤー)

この設計により、データ レイヤーをプレゼンテーション レイヤーから分離しておくことができます。Web プロジェクトは EntityModels プロジェクトについて何も知らず、その逆も同様です。すべてのロジックはビジネス レイヤーにあります。

コントローラーから (検証チェック後)、ビューモデルをサービス層に渡し、マッピングと必要なすべてのビジネス ロジックが実行されます。

このデザインは本当に正しいですか？

私の意見は、ViewModel はプレゼンテーション層で定義する必要があることを読んだことです。プレゼンテーション層がデータ層への参照を持ち、マッピングがコントローラーで行われる例を見ました (良い習慣ですか?)。この場合、コントローラーはドメイン モデルをビジネス レイヤーに渡します。私はここでの経験はありませんが、好きではありません。

それで、誰かが私が正しいところと間違っているところを指摘できますか?

前もって感謝します。

4

2 に答える 2

3

全体的にアーキテクチャは良さそうです。ビュー モデルをどこに配置するかの決定は、私の意見では 1 つの要因に左右されます。

今後、これらのビュー モデル (iPad、Android など) を再利用することでメリットが得られる可能性のある他のクライアントを用意する予定はありますか?

その場合は、それらを MVC アセンブリから除外し、独自のアセンブリに配置してください。それ以外の場合は、2 つ目のクライアントを作成することにした場合に、それらを移動してコードを変更しても問題ない限り、それらを MVC アプリに配置しても安全です。

記録のために、私は常に自分のビュー モデルを独自のアセンブリに配置します。前もって時間がかかることはありませんが、状況が変化した場合に将来的に利益をもたらします。

于 2011-07-12T16:36:45.497 に答える
1

FWIW、私は同じことをしていますが、MVCは初めてなので、100％確実に正しい方向に進んでいるわけではありません。しかし、それはただ「正しいと感じる」だけであり、それはほとんどの場合、それが正しいことを私に教えてくれます。追加する唯一のことは、automapper（automapper.org）を使用することです。これにより、レイヤーを持つオーバーヘッドがほとんどなくなります。ぜひIMOをチェックしてください。100％正しくないと感じているのは、このパターンを使用して、ビューごとに1つのViewModelを大量に作成していることだけです。各ドメインエンティティの作成、インデックス作成、更新、詳細にはそれぞれ独自のViewModelがあるということですか？または、ビュー間で1つのViewModelを共有していますか？最後に、私はjfarsの議論を購入しません。それは、多くの複雑さ/ビルド時間を作成します。少なくとも、それは概念的にそれだけ多くの層を分離します。
私は、ビューモデルをSilverlightの実装に再利用するという夢を抱いていますが、それを実際に考えたことはまだありません。しかし、すべての「非UI」コードをビューモデルとサービスに分解するという良い仕事をするなら、新しいUIを実行することは「取るに足らない」はずですよね？表示されます:-)

于 2011-09-16T00:26:04.557 に答える