モデルクラスの数は？テーブル数？ビュー数？

MVCのモデルクラスについて質問です。

例えば、伝票テーブルと、伝票明細テーブルがあったとき、
（伝票テーブル：伝票番号 100 取引先A

　伝票明細テーブル：
　　　伝票番号 100 商品A 100円 15個
　　　伝票番号 100 商品B 200円 10個　
のようなもの）


「モデルクラス」は
「伝票テーブル操作用」と
「伝票明細テーブル操作用」に分けるべきでしょうか？
それとも分けないべきでしょうか？

私は、
SELECT用なら「伝票テーブルと伝票明細テーブルを結合した状態でモデルクラスをつくる」
INSERT、UPDATE、DELETE用なら「伝票テーブル用」と「伝票明細テーブル用」に分けているのですが、
この方法はあっているでしょうか？

大抵のテーブルが参照オンリーではなく登録系も必要であるシステムなら、
「テーブル数」＝「モデルクラス数」とし、

参照をメインにするようなシステムなら
「ビューの数」＝「モデルクラス数」とする認識です。

No.2 ベストアンサー 回答者： shockatz 回答日時： 2015/01/06 03:02

その認識でほぼ合っていると思います。

ASP.NETのような統合化された処理系ならば、テーブル操作用のクラスは、DAL（データアクセスレイヤ）として、LINQ for SQLやEntity Frameworkで自動的に作成されてしまいます。

ただ、そのようなクラスをそのまま更新系のモデルとして使いますと、CRUDに必要なメタデータ（検証用属性など）が不足したり、また参照系でも付加的な表示要素を埋め込んだ方が扱いやすいので、DALを継承したクラスを「ビューモデル」として作成する事になると思います。

結合モデルについては、AutoMapper のようなマッピングモジュールを使って「フラットな」クラスに詰め替える方法や、DAL（を継承した拡張クラス）を要素にした「入れ子」クラスを使う事など、いくつかの方法があります。

いずれの場合も、.NETの特長である強力なDALを生かしつつ、ビュー中のコードをできるだけ排除するため、すっきり洗練されたビューモデルを設計することが開発のキモになると思います。

Automapper
http://news.mynavi.jp/articles/2009/12/10/automa …

この回答へのお礼

回答ありがとうございます！

データ取得の部分については、
DAL（データアクセスレイヤ）として、

LINQ for SQLや
Entity Framework　が便利ということなので、
DALを継承したクラスを「ビューモデル」として作るやり方を調べてみようと思います。

AutoMapper ？
マッピングモジュール？というのを使って
「フラットな」クラスに詰め替える方法や、
DAL（を継承した拡張クラス）を要素にした「入れ子」クラスを使う事など、
非常に興味深いです。

今回はJavaでの開発なのですが、
ASP.net を使う際には是非ともこのように作ってみたいと思います。

お礼日時：2015/01/07 10:44

No.1 回答者： shitaba 回答日時： 2014/12/29 22:36

※ モデルクラスではなく、あえて『エンティティクラス』

　 と言い換えて回答します。(MVC の『モデル』は、そも
　 そもデータストア(テーブル)に依存して設計するもので
　 はありませんので…)

設計方法に依存するので何とも言えない部分はありますが、
『優秀な O/R マッピングツール』を使わない前提であれば、
私も質問者さんのおっしゃる通り
　・SELECT用なら「伝票テーブルと伝票明細テーブルを
　　結合した状態」でエンティティクラスをつくる
　・INSERT、UPDATE、DELETE用なら「伝票テーブル用」
　　と「伝票明細テーブル用」に分ける
ように作るのが使いやすいと思っています。

また、『「伝票テーブルと伝票明細テーブルを結合した状態」
で取得したデータを、画面に表示。ユーザが画面上で編集して
その内容を登録する』という機能もよくありますが、その場合
はデータ取得・表示時は「結合したエンティティ」を使い、
登録時は「テーブル毎のエンティティ」に詰めなおすように
設計します。

そうしますと、私の設計では
　エンティティクラス数 ＝「テーブル数」+「ビューの数」
になります。もちろん、ビューの数が多くなると変更管理が
面倒なので、なるべく少なくなるように設計を工夫しますが。