ドメインモデルとビューモデル
私はプログラミングのキャリアの初期段階にあり、MVCとは約1年間働いています。パターンとその背後にある概念について学ぶことに多くの時間を費やしてきましたが、私が取り組んでいるプロジェクトが大きくなるにつれて、モデルレイヤーがどのように想定されているかを十分に理解していないと思い始めています仕事に。
ドメインモデルを保護するために常にビューモデルを使用することについてはよく耳にしますが、実際にはどのように機能しますか？ 2つの間の関係はどのように見えますか？モデルに追加の「表示」ロジックが必要ない場合は、そのコピーを作成するだけでよいですか？どうして？
あなたはまさに正しい質問をしました：「なぜ？」
MVC、MVP、MVVM、そしておそらくそれらの数千の小さな偏差...そこには非常に多くの設計パターンがあり、その違いは非常に微妙です。アプリケーションのGUIレイヤーを設計する方法を明確に理解する唯一の方法は、おそらく頼りにして、要件を収集し、それらを互いに比較することです。例えば、
- 自動GUIテストが必要ですか？どこまで？
- 画面には、データバインディングでは簡単にカバーできない「複雑な」動作が含まれていますか？幾つ？
- プラットフォームに依存しない必要がありますか？
- 再利用する可能性が高いコンポーネントはどれですか？たとえば、アプリケーションが対象とする画面サイズは大きく異なりますが、すべてのビジネスロジックを再利用したいですか？
例：
自動テストを実行せず、Swingプラットフォーム（画面解像度の範囲が比較的狭いPC）のみを対象とすることがわかっている場合は、コードを3つのクラスに分割して、Swingに依存しないビューモデルを作成しないでください。 。あなたはそれから何も得ません。
一方、自明ではないビジネスロジックがあるために自動テストを必要とするGWTアプリケーションを開発する場合、MVPが提供する疎結合を利用して、軽量な方法で（つまり、純粋なJava環境）のGWTコンポーネント。
アプリケーションとテクノロジースタックの特定の要件 ...についてすべてです。そして、それがおそらく、同じパターンの非常に多くの生まれ変わりがある理由です。
かなり一般的な答えです。従来、MVCのビューはモデルに必要な情報を要求し、モデルはビューについて何も認識していませんでした。データバインディング（Microsoft UIで非常に人気があります）は、ビューを基本的なモデルに非常に密接に結び付けます。これは、従来のMVCと競合します。
したがって、解決策は、バインドするビューの1つのモデルと、実際にはモデルである別のモデルを用意することです。これらはビューモデルとドメインモデルです。
あなたの質問へ：それらの間の関係は、VMはDMについて知っているが、その逆ではないことであり、VMは、使用するビューこれらの要件を持つビューがない場合、ビューモデルはまったく必要ありません。
VMが必要な場合は、DMのラッパーとして考えることをお勧めします。VMは、表示に固有のプロパティを持ち、ビジネスデータの要求と更新をDMに委任します。それらの間でロジックが重複することはありません。
これをWPFまたはストアアプリで使用した場合、VMはビューのデータバインディングコンテキストであり、近接しており、DMおそらく遠く離れた正式なインターフェース。
これにパターンがあるかどうかはわかりません-私の心はそのようには機能しません。