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は後発だけあっていろいろとアドバンテージがあるので、私はこちらをオススメします。