Javaの「BeanUtils.copyProperties」は非常に便利な機能ですが
適切な利用が本当にされているでしょうか？
今回はEntityとDTOおよびFormのパターンについて語りたいと思います。
※DTOだけデザインパターンなのにこの名称で語られるのに違和感がありますが・・・
EntityとDTOおよびFormはBeanとして実装されるケースを見ます。
しかし、その理由が「BeanUtils.copyProperties」を利用したいだけになっていませんか？
例えばこんな実装
class EntityBean
{
private int value;
public int getValue(){ return value; }
public void setValue(int value){ this.value = value; }
}
class DtoBean
{
private int value;
public int getValue(){ return value; }
public void setValue(int value){ this.value = value; }
}
class FormBean
{
private int value;
public int getValue(){ return value; }
public void setValue(int value){ this.value = value; }
}
Entity、DTO、Formに同じフィールドを持てば「BeanUtils.copyProperties」を
利用することは確かにでき、便利だと思います。
しかし、よく考えてみてください。
Entity、DTO、Formは異なる実装を吸収するためにあるものではないでしょうか？
「BeanUtils.copyProperties」を利用したいがゆえに同じフィールドを持つことを
強制していないでしょうか？ そうなってしまうと変化に強くもなく、データベースの仕様を
Entity、DTO、Formの3箇所を人力で運用し続けなければならなくなります。
#DBの仕様変更でフィールド名を変更した場合
Entityのvalue -> hogeに変更しました。
class EntityBean
{
private int hoge;
public int getHoge(){ return hoge; }
public void setHoge(int hoge){ this.hoge = hoge; }
}
class DtoBean
{
private int value;
public int getValue(){ return value; }
public void setValue(int value){ this.value = value; }
}
class FormBean
{
private int value;
public int getValue(){ return value; }
public void setValue(int value){ this.value = value; }
}
これって「BeanUtils.copyProperties」を使う限りビルドは通るし
それなりに動いてしまう可能性があります。DTOとForm作っている人に(もしかしたら自分)に
伝達して、修正してもらわなければなりません。動作を維持するならテストコードも必要になります。
ここまでのコストを支払う価値ってどこにありますか？
実装ミスってませんか？
Entity、DTO、Formの3箇所に同じフィールドを持つことを強制する(できる)のであれば
実装としては継承が適切です。
class EntityBean
{
private int hoge;
public int getHoge(){ return hoge; }
public void setHoge(int hoge){ this.hoge = hoge; }
}
class DtoBean extends EntityBean
{
}
class FormBean extends DtoBean
{
}
同じフィールドを持つことを担保できますし、変更があればコードレベルで
変わってくるので、ビルド時のエラーに気づけます。
継承しているので、プロパティを削りたければアップキャストすれば実現可能になり
「BeanUtils.copyProperties」を使う必要は全くありません。
でもEntity、DTO、Formの3箇所に同じフィールドを持つというのは、そもそもの目的を潰していませんか？
本当にやりたいことはこういうことのはず。
class EntityBean
{
// Entityでは日付を日付型で持つ
private DateTime date;
public DateTime getDate(){ return date; }
public void setDate(DateTime date){ this.date = date; }
}
class DtoBean
{
// DTOでは日付を文字列型で持つ
private String date;
public String getDate(){ return date; }
public void String(String date){ this.date = date; }
}
class FormBean
{
// Formでは日付を年月日別で持つ
private String year;
private String month;
private String day;
}
「Entity、DTO、Form」がそれぞれ異なる実装を持つ可能性があるからこそ
分けるのであって、同じ実装が前提になっていたら何の意味もないのです。
「BeanUtils.copyProperties」を使う限り、抽象度は低く何の備えにもなっていません。
そもそもですが、「Entity」と「Form」の変換は誰が担うべきなんでしょうか？
「BeanUtils.copyProperties」を使うことで責任をうやむやにしていませんか？
ちなみに上記の例に限って場合「DTO」って誰得の何の役割を持つのでしょうか？
私は不要だと考えます。DTOは複数のEntityと絡みがない限りは必要ないのです。
本当は「Entity」と「Form」の変換の役割に担う別の人が必要になります。
class EntityBean
{
// Entityでは日付を日付型で持つ
private DateTime date;
public DateTime getDate(){ return date; }
public void setDate(DateTime date){ this.date = date; }
}
class Converter
{
// 相互に変換するメソッドを用意してこいつが責任を負う
public static EntityBean convert(FormBean form) ... 実装は割愛
public static FormBean convert(EntityBean form) ... 実装は割愛
}
class FormBean
{
// Formでは日付を年月日別で持つ
private String year;
private String month;
private String day;
}
「Converter」の中で、「BeanUtils.copyProperties」を使うのであれば
抽象度は保たれていると思います。
Entity、DTO、Formの3箇所に同じフィールドを手動で作成してかつ
それを設計上の前提条件として「BeanUtils.copyProperties」を利用している
ケースはみなさんの周りにはないでしょうか？
本当にそれって正しいのか？ 私は疑問に思います。
ご意見ご感想お待ちしております。