繰り返し項目の実装はDtoとEntityのどちらを使うべきか？

SAStruts

『複数レコード処理（繰り返し）』の場合に、Entityをそのまま使うというのに違和感を感じてしまうのですが、そんな感覚にはこだわらない方が良いのでしょうか。


導出項目を得るような処理というのはプレゼンテーションロジックなのだから、DTOに値をコピーして、DTOのgetterで実装するようにした方が良いような気がしてしまっているのですが。

私の以前のエントリでは、繰り返し更新がなければDtoのではなく、Entityを積極的に使うことを書きました。でもDtoを使うケースでも特に問題ないと思います。ただし、メリット・デメリットは、把握しておいた方がいいと思います。


【メリット】

  • 繰り返し処理には、常にDtoを使うため、設計に一貫性がでる。実装者も迷わない。

【デメリット】

  • プレゼンテーションモデル側で導出項目のロジックを用意すると重複しやすい。
  • 繰り返し更新が必要となるケースは比較的少ない状況において、手軽にEntityで実装できてしまうものをわざわざDtoを作るのが面倒。
  • EntityからDtoへの詰め替えコストも掛かってしまう。


この手の問題は、以前に書いた以下のエントリの問題に帰着すると思います。


　「８割の簡単な処理」と「２割の複雑な処理」への対処方針
　http://d.hatena.ne.jp/dewa/20080531#1212211267


Dtoを使うパターンは以下に相当します。

[方針２] ２割の複雑な処理にあわせる 
品質重視。ただし、簡単な処理の生産性は落ちる。


状況に応じて、EntityとDtoを使い分けるパターンは以下に相当します。

[方針３] 両方の対処方法を用意して、使い分ける 
最適化重視。ただし、厳密な使い分けは難しい。


そんな訳で、どちらの方針を取るべきかは、プロジェクト単位で
決めてしまえば良いと思います。開発コストと設計の良さとのトレードオフですね。
どちらの方針も悪くないと思います。
大切なのは、一旦方針を決めたらそれを徹底することではないでしょうか。