過去に、ドメインとビューに同じモデル オブジェクトを再利用すべきではないというモデルに関する MVC のアドバイスを読みました。しかし、なぜこれが悪いのかを議論してくれる人を見つけることができませんでした.
ドメイン用とビュー用の 2 つの別個のモデルを作成し、それらの間でマッピングを行うと、多くの重複と、退屈なマッピング コード (一部はAutoMapperなどによって軽減される可能性があります)が作成されるというのが私の意見です。エラーが発生しやすくなります。
2 つの懸念事項に対して個別のモデルを用意することで、コードの重複とマッピングの問題を解決する価値があるのはなぜでしょうか?
その中心にある 2 つのモデルは、関心の分離に関するものです。ビューを単一のモデルで動作させたい。ドメイン モデルが、ドメインの専門家と一緒に構築した概念モデルを表していることを望んでいます。ViewModel には多くの場合、技術的な制約があります。ドメイン モデルは POCO に関するものであり、表示されるデータ (ビュー) または永続化されるデータ (DB など) の技術的な制約に縛られることはありません。
画面に 3 つのエンティティが表示されているとします。つまり、3 人の関係を強制する必要があるということですか? または、3 つの項目すべてを含む ViewModel コンポーネント オブジェクトを作成するだけです。別の ViewModel を使用すると、View の懸念は私のドメインから分離されます。
なぜ？ビューにはモデル オブジェクトを使用する機能がないためです。
プロジェクトを Web デザイナーに渡してビュー レイヤーを作成してもらうとします。突然、モデル層を介してアプリケーションのデータを操作できるようになります。それは良いことではありません。
したがって、メソッドを持つオブジェクトではなく、常にビューが必要とするデータのみを渡します。
JP Boodhoo の記事Screen Bound DTOsは、設計上の利点を理解するのに役立ちます。
私が書いたセキュリティ上の利点もあります。
プレゼンテーション モデルを使用すると、ビューが簡素化されます。通常、ビューはテストが非常に難しいため、これは特に重要です。プレゼンテーション モデルを使用することで、多くの作業をビューからドメイン -> プレゼンテーション モデルに移すことができます。書式設定、null 値の処理、オブジェクト グラフの平坦化など。
追加のマッピングが苦痛であることには同意しますが、特定のコンテキストで両方のアプローチを試して、何が最適かを確認する必要があると思います.
特別にフォーマットされ、確かにnullセーフであるビューモデルの機能を含む、さらに明白な懸念があります。
ルールも重複しているようです。
すなわち。UI でクライアント オブジェクトを検証してから、検証する必要があるドメイン オブジェクトにマッピングします。
ただし、私がよく行うのは、一連のドメイン オブジェクトをマップしてモデルを作成することです。顧客情報、在庫情報などを表示する Web ページ...私のモデルは、Customer オブジェクトと Stock オブジェクトを保持する構造になります。
CompanyPageModel
public Customer Customer{get;} public Stock Stock {get;}
次に、私のmvcプロジェクトで ViewData.Model.Customer.Name ViewData.Model.Stock.CurrentStocks
分離はより多くの作業のように見えますが、後で、UI/ドメイン モデルのこの分割を行うのは良いことです...テストを書くようなものです :)
ドメイン モデルは、MVC アプリケーションだけでなく、他の実装にも拡張される可能性があり、それによって懸念の分離の原則が破られる可能性があると思います。ビュー モデルがドメイン モデルである場合、ドメイン モデルには、ドメイン変更要件とビュー要件変更の 2 つの変更理由があります。
私は最終的にクールな補佐官を飲みました。ビューモデルに表示命令をマークし、それをすべて自動配線できるのが好きです。
私が今求めているのは、poco エンティティからのビューモデルのある種の自動生成です。私はいつもいくつかの文字列を int として設定しており、それを見つけるのに永遠に時間がかかります。苦痛が好きでない限り、オートマッパーなしでこれを行うことさえ考えないでください。