DTO

今、くーすを使った開発をやっていて、先行して始めた部分がほぼ出来上がろうとしているのですが、データのやり取りは、DTOを使っていて、Entityは結局使ってません。
Entityを使う場合は、Entityの構造とプレゼンテーション層で必要とする構造が異なるため、ViewHelperをかませるというのが、ポピュラーな方法ですが、これが結構手間です。Entityとプレゼンテーション層のデータ構造の変換を入力と出力の両方でやる必要があります。
それだったら、最初からプレゼンテーション層で扱いやすい構造のDTOを定義して、やり取りした方がいいジャンという考えです。
ただし、この方法は、O/Rマッピングのフレームワークが、任意のDTOにSELECT文の結果セットをマッピングできなければなりません。そうでないと、誰かが構造の変換を行わなければならないためです。
Hibernateを使う場合は、ViewHelperを使ったほうが良いでしょう。
S2Daoを使う場合は、クライアントで扱いやすいDTOを定義して、SELECT文の結果をダイレクトにマッピングします。
今お勧めのやり方は、Entityはテーブルと同じ構造にして、N:1などのリレーションは定義しない。永続化されるデータを持つDTOは、Entityを継承して、プレゼンテーション層に都合のいい項目を追加するというものです。
プレゼンテーション層のための項目の代表は、なんとか名称でしょう。3つくらいテーブルをジョインしないと持ってこれなかったり、コードと名称が汎用的に登録されている汎用コードテーブルから持ってくる場合などは、マッピングを定義して、テーブルのすべての項目を持ってくるよりは、さくっと必要な項目だけをジョインして持ってきたほうが楽だし、パフォーマンスもあがります。
更新は、S2DaoがSQL文を自動生成してくれるのでDTOを使っても楽チンです。


前に、はぶさんに層間のデータのやり取りが全部DTOってのは違和感あるって言った気がするけど、結局DTO使うほうが楽みたい。楽で工数を減らせるほうに直ぐに転ぶってことで。(^^;


追記:
ValueObjectよりは、DTOが良いとおもいます。-> はぶさん
ファウラーたんが、immutableなのがValueObjectだっていってるから。