DomainModelとか、ViewModelとかのお話

ASP.NET MVCでWebアプリを作っているときに、いつも迷うのが、Model配下のオブジェクト定義です。

DomainModelは大体、Models配下にDtoフォルダを作成して配置しています。
SQLのスクリプトは、Models配下にSqlフォルダを作成して配置しています。
コード上で参照したいので、Sqlフォルダ内のスクリプトは、アセンブリリソースファイルを作成して管理しています。

毎回、悩むのが、Dtoフォルダ内が、若干ゴミ箱っぽくなる点です。

本来は、ドメインモデルは、機能に必要な単位で定義するべきものです。
一旦はテーブルの射影のエンティティクラスでデータを受けてあげて、そこからリポジトリクラスなりで、複数のエンティティクラスから、ドメインモデルに必要なデータをかき集める、と言うのが、意味合いとしては正しい気はします。

DB→Entity→マッピング処理→DomainModel　みたいな流れでしょうか。

……が、EntityからDomeinModelへ毎回データマッピングするのが正直、辛いです。
必ずしもEntityで受ける必要もないのかなーと最近は思っています。（DomainModelでクエリ結果受けてもいいかなーと。）

ついでに、ViewModelについてですが、この子はViewの射影なので、意味付けとかは特に関係なく、定義しているビューに合わせて定義します。
例えば、社員情報編集、といった機能であれば、編集対象の社員情報、役職の選択肢リスト、部署の選択肢リストといった、意味の異なったオブジェクトが必要になります。
これらをかき集めた集合のオブジェクトとして１つのViewModelを作成します。
あくまでViewModelはViewのためのデータ集合なので、割合ごちゃ混ぜな定義になりがちです。

また、表示やバリデーションに使用するアノテーションはViewModelに記述します。
ここも、また悩みどころで、ViewModelが、DomainModelと似通っている場合、そもそもViewModelっているのか問題があります。
その場合、アノテーションを、DomainModelに書いていいのか問題が発生します。
DomainModelは機能に必要な単位で定義されたものなのに、表示に必要なアノテーションをDomainModelに書いてあるのが、どうなのか、というお話ですね。
その時々で、考え方は変わるので、時々考えていきたい問題です。