ローカルDTO
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?LocalDTO
DTOには、主に3つの目的があるように思います。
- リモート呼び出しの回数を抑えるための大きなデータの入れ物
- オブジェクト間(層間)でデータをやり取りするための入れ物
- プレゼンテーション層のモデル
分散アプリケーションは、ほとんど必要ないというのが最近の流れなので、1の目的で使われることは少ないでしょう。
2と3はセットで考える必要があります。
2の問題点は、ドメインオブジェクトとDTOの相互変換をするのはコストがかかるという点です。これは、私も同意しますが、結論を出す前に3を考えてみましょう。
プレゼンテーション層のモデルとしてDTOを使うというのが、DTOの最も適した使い方だと思います。
Fowlerはプレゼンテーション層で必要とされる構造とドメインオブジェクトの間にミスマッチがあるときだけ、DTOを使えといっていますが、たいていの場合(よほど単純な画面でない限り)、ミスマッチはあるものです。
また、プレゼンテーション層でドメインモデルの構造を理解して入出力のロジックを組み込むのも良くありません。プレゼンテーション層は、プレゼンテーションに徹し、ドメインの知識は持つべきではないからです。プレゼンテーション層は、テストしにくいので、できる限り単純にしたほうが良いという考え方もあるでしょう。
そう考えていくと、プレゼンテーション層のモデルとして、DTOを使うというのは、理に適ったことだということが分かります。
3が必要だということをふまえて2に戻りましょう。
オブジェクト間(層間)でデータをやり取りするためにDTOを使うこと自体は問題ありません。問題なのは、ドメインオブジェクトとDTOの相互変換のコストです。このコストはばかになりません。
そこで私が主張するのは、RDBMS<->ドメインオブジェクト<->DTOではなく、直接、RDBMS<->DTOしてしまえというものです。これなら、ドメインオブジェクトとDTOの相互変換のコストはかかりません。業務ロジックは、Statelessな業務ロジック層(サービス層)にもたせます。
DTOをこのように使うときに重要なポイントがあります。DTOはエンティティ(ドメインオブジェクト)を継承するということです。DTOの構造をプレゼンテーション層の都合のみで考えると、同じような業務ロジックが分散する危険があります。
これは、どのようなドメインにもいえます。再利用性の高いロジックも業務ロジック層におけるからです。
