繰り返し項目の実装は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を使い分けるパターンは以下に相当します。

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


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

S2DxoとBeans(S2BeanUtils)、どっちがどうなの？

Seasar2

SAStrutsでは、「S2DXOは、もはや使用しない」という見切りがつけられてしまっているようなのですが、どうしてそのように見切ったのか、ということは、まだ、公開された場所では説明されてないようにも思います。案外、Listの変換に使用するとS2DXOの処理は重いものになってしまっているのでしょうか。

私はプロダクトの開発者ではないのですが、

S2DxoとBeans(S2BeanUtils)についての自分なりの考えは以下のとおりです。


S2DxoもBeansも同じ役割のユーティリティで、実際に、簡単なケースだと両方とも大差ないと思っています。ただし、複雑なデータ変換の場合だと、Beansの方が優れているように思えます。

その理由としてBeansは、

  • 簡単なケースはBeansを用いて自動変換
  • 複雑なケースはゴリゴリ手書き変換

の２つの処理を同一メソッド内に手軽に併用できてしまからです。この地味な利点が何気に大きなアドバンテージだと思っています。

メソッド内で併用できるので、どちらのやり方でも良い。メソッドさえ定義しておけば、その内部処理方針をころころ変更してもよい手軽さが、自分的には大ヒットでした。

（あまり良い例ではないですが）コードのイメージはこんな感じです。

public EmployeeDto createEmployeeDto(Employee emp) {
    /* 簡単なケース(Beansを用いた自動変換) */
    EmployeeDto dto = Beans.createAndCopy(EmployeeDto.class, emp);

    /* 複雑なケース(手書きで変換) */
    dto.employeeId = emp.id;
    dto.employeeName = emp.name;
    dto.departmenName = emp.department.name;

    return dto;
}

実際にBeans触ってみて『簡単な処理は徹底的に自動化させて、複雑な処理はフレームワークが頑張りすぎずに明示的にソースコードを書く』といったコンセプトをそのままコードに反映できる感じがしました。

複雑な詰め替え処理を含むケースでも、簡単な箇所は自動変換と併用できるので適度に生産性が高くて、ソースコードの可読性も高い、そして、テストしやすいという印象を受けました。


一方、S2Dxoだと、複雑な変換において、自動変換と手書き変換を１つのメソッドに収めようとすると、ちょっと無理があるというか、やや大掛かりになってしまいます。だからといって、自動変換を使わずに全て手書きで変換するのも大変だし、アノテーションを駆使しまくって自動変換させるのも大変だと思います。


ぶっちゃけ、私の頭のイメージはこんな感じです。

  • S2Dxo
    • わざわざ専用のインターフェースクラスを作成した後に、タイプセーフじゃないアノテーションの属性に苦戦を強いられる
  • Beans
    • 流れるようなインターフェースでサクサク感が出やすい。ハマる位ならば手でゴリゴリ変換する。

そんな訳で、S2DxoよりもBeansは後発だけあっていろいろとアドバンテージがあるので、私はこちらをオススメします。