S2DxoとBeans(S2BeanUtils)、どっちがどうなの?
SAStrutsでは、「S2DXOは、もはや使用しない」という見切りがつけられてしまっているようなのですが、どうしてそのように見切ったのか、ということは、まだ、公開された場所では説明されてないようにも思います。案外、Listの変換に使用するとS2DXOの処理は重いものになってしまっているのでしょうか。
私はプロダクトの開発者ではないのですが、
S2DxoとBeans(S2BeanUtils)についての自分なりの考えは以下のとおりです。
S2DxoもBeansも同じ役割のユーティリティで、実際に、簡単なケースだと両方とも大差ないと思っています。ただし、複雑なデータ変換の場合だと、Beansの方が優れているように思えます。
その理由としてBeansは、
- 簡単なケースはBeansを用いて自動変換
- 複雑なケースはゴリゴリ手書き変換
の2つの処理を同一メソッド内に手軽に併用できてしまからです。この地味な利点が何気に大きなアドバンテージだと思っています。
メソッド内で併用できるので、どちらのやり方でも良い。メソッドさえ定義しておけば、その内部処理方針をころころ変更してもよい手軽さが、自分的には大ヒットでした。
(あまり良い例ではないですが)コードのイメージはこんな感じです。
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だと、複雑な変換において、自動変換と手書き変換を1つのメソッドに収めようとすると、ちょっと無理があるというか、やや大掛かりになってしまいます。だからといって、自動変換を使わずに全て手書きで変換するのも大変だし、アノテーションを駆使しまくって自動変換させるのも大変だと思います。
ぶっちゃけ、私の頭のイメージはこんな感じです。
- S2Dxo
- わざわざ専用のインターフェースクラスを作成した後に、タイプセーフじゃないアノテーションの属性に苦戦を強いられる
- Beans
- 流れるようなインターフェースでサクサク感が出やすい。ハマる位ならば手でゴリゴリ変換する。
そんな訳で、S2DxoよりもBeansは後発だけあっていろいろとアドバンテージがあるので、私はこちらをオススメします。