MVCでは、1つのモデル1のテーブルまたは1つのモデルのいくつかのテーブル？

Question

MVCでは、1つのモデルを1つのテーブルまたは1つのモデルをいくつかのテーブルですか？

私は3つのテーブルを含むアプリケーションを構築しています。 3つのテーブルすべてに対して1つのモデルを作成するのか、3つのテーブルに対して3つのモデルを作成するのかはわかりません。

3つのモデルを3つのテーブルに使用している場合、これらの3つのテーブルを結合するにはどこにコードを入れる必要がありますか？ 3つのモデルのいずれかにコードを挿入しますか？

提案がありますか？

Answer 1

通常、テーブルごとに1つのモデルを作成するので、3つのモデルが必要な場合があります。 私が "モデル"と言うとき、私は、単一の行を（通常は）単一の表に表すクラスを意味します。

例えば： テーブル：

1. 製品
2. 注文
3. 顧客

このような場合には、最も簡単で単純なデータを表す3つの異なるクラスを（作成することですアプリケーションのモデル）。第1クラスは単一の製品を表し、次は注文を表し、最後のクラスは単一の顧客を表します。

Answer 2

一般に、MVCの 'Model'部分は、 'Presentation Model'または 'View Model' - つまり、Viewに必要なすべてのデータと動作をカプセル化するクラスとして解釈される必要があります。これは、ドメインモデルと同等であってもなくてもよい。

ドメインモデルは、UIから独立するように設計する必要があります。つまり、そのようなモデルは、特定のボタンが有効かどうかの判断など、UI固有のデータと動作で汚染されるべきではありません。

同じドメインオブジェクトをいくつかの異なるビュー（マスター/ディテール、または表示/編集など）で表示し、それらのビューが十分に異なる場合は、各ビューのビューモデルを有効にすることもできます。

一般に、ドメインレイヤーとプレゼンテーションレイヤーを個別に設計する必要があります。

ドメインレイヤーでは、3つのテーブルを3つのクラスとしてモデル化することができます。 FowlerのPatterns of Enterprise Application ArchitectureとEvansのDomain-Driven Designのような書籍には、リレーショナルデータをドメインモデルとしてモデル化する方法に関する多くのガイダンスが含まれています。

MVCでビューをモデリングする場合、ビューごとに1つのモデルを作成することが最も理にかなっています。このようなビューモデルは、単一のドメインオブジェクトを単純にカプセル化するだけでなく、複数の異なるドメインオブジェクトをカプセル化して集約することもできます。

このようにして、懸念事項を確実に分離し、クラスが単一責任原則に従うようにすることができます。

非常に単純なシナリオでは、ドメインモデルとプレゼンテーションモデルを1つのレイヤーに折り畳むことは意味がありますが、これは本質的にソリューションにドメインモデルがないことを意味するはずです。すべてのモデルは純粋なプレゼンテーションモデル。