BeanUtils.copyproperties()で利用しても良い/悪いの境界線とは

Question

最近apache.commonsのBeanUtils#copyProperties()が便利なのでよく利用しているのですが、
基本的にコピー元とコピー先に同名で同じ型の変数があることを期待しているわけですよね。

「DBEntity <=> DTO」みたいな場合は利用する際にはそれ程気にならないのですが、
「各Class <=> 共通DTO」みたいな場合でも利用して良いのでしょうか？
それとも、Interfaceを作成して各Classに実装したうえで、
DTOに対して値をコピーする方が良い実装なのでしょうか？

コピー元・先の実装に依存するので、どこまで利用範囲を広げて良いのかとても悩みます。
変数名に対する命名規則が厳格に定まっている場合にのみ、
「各Class <=> 共通DTO」を利用しても良いのかなとも思っています。

Answer 1

"変数名に対する命名規則が厳格に定まっている場合" よりも、共通DTOと実際に扱うDTOとのフィールド差分をどこまで許容するかのインタフェース設計が大事になるでしょう。

BeanUtilsの良いところでもあり、あまり良いところではないとも思えるところですが、転写元のインスタンスがもつフィールドを、転写先は全てもつ必要がないので（ランタイム例外にならない）、おっしゃる通り、厳密なルールでDTOを設計したいのであれば、インタフェースを用意して必須のフィールドに対するset/getメソッドなりを定義するのも1つの手です。

Comments

[cha-ra]

必ずしも一致するとは限らない変数名よりも、
基本的にはインターフェースでのやり取りの方が安心／安全ですね。

同じ型同士だったら問題なくコピー出来るとは思いますが、
clone()を利用する手もあるので、そうなってくるとBeanUtilsの使いどころってどこなんなんだろう？って益々悩んでしまいます。

[A-pZ]

まさしくそこが肝となるところでして、完全転写するならBeanUtils使うことはないのですが、片方にだけ存在するフィールドを無視して転写できるのが強みです。

セッション情報を一部コピーしてDTOに詰める場合や、入力データと出力データとで似たようなDTOを扱う場合に、部分的に表示したくないフィールドがあった場合などに、1つ1つ転写するのではなく、一括でコピー→存在しないフィールドなら無視する、といった使い方もできます。

Answer 2

<=>
この意味がわからないので答えられません。。

Comments

[退会済みユーザー]

基本的に相互変換（文字化け回避）

[tantanegg]

ご教授ありがとうございます。
個人的にはcopyProperties()は裏技だと思っています。
（DBEntity <=> DTO）は便利なので使ったほうがいいと思いますし使いますが、
それありきで考えるのは私はあまりしたくありません。

[退会済みユーザー]

まあ私もコンバータ自作を使うね。

拡張時に余計なコピー抑止のため

フレームワークが使っているのはしょうがないが