DTOの利用の注意点
ローカルDTOの議論に以下のような点があります。
「 DTOを使うコストを過小評価するな。それは深刻かつ困難なものなのだ―― オブジェクトリレーショナルマッピングに次ぐコストと苦労が強いられるぞ。」
これらは何を言っているかというと、DTOを不必要に導入しない。画面もドメイン層のオブジェクトをそのまま利用しなさいといっています。そうしないとコストがかかるよということです。
また良く勘違いしてしまうのですが、サービス層で受け渡しているビジネスオブジェクトを全てDTOと考えてしまうことがあるが、DTOは転送のためにドメイン層のデータとは違う構造を持ったオブジェクトとして作成するものです。
テーブルモジュールなんかの場合、サービス層を導入してもレコードセットをそのまま転送データとして利用できるのでサービス層を導入コストが低くなります。というかテーブルモジュールの場合、ドメインモデルをDTOで代用しているようなモデルなので当たり前の結果ですね。
結局何を言いたいかというと、少なくとも、各レイヤでビジネスデータの表現形式をあまりかえるようなことはしないほうが良いよということ。DataSetならDataSet、POCOだったらPOCOを全てで使うようにするということ。
あとローカルDTOの議論のなかで以下の内容は少しミスリードする可能性があるので注意が必要だと感じました。この説明を読むとDTOはプレゼンテーションのために特化してよいデータ、画面構造に依存してよいものと考えてしまいますが、DTOは転送のためのデータなのであくまでも画面に渡すデータとして特化するものと受け取ったほうが良いと考えています。
ここでのファサードはアプリケーションファサードで、ドメイン層のオブジェクトを使ってアプリ機能を実現したメソッド（≒サービス）を提供するものです。
DTOのようなものを使うとよいのは、プレゼンテーション層のモデルとドメインモデルとの間に大きなミスマッチがある場合です。この場合、プレゼンテーションに特化したファサード（またはゲートウェイ）を作り、ドメインモデルをマッピングして、プレゼンテーションに都合のよいインターフェースを提供するのは理に適っています。これは Presentation Model とも合います。
