DAOとかVOとかDTOとか

tech

設計、コーディングで用いられる言葉の整理。こいつらって何よ？

  • DAO(データアクセスオブジェクト)
  • VO(バリューオブジェクト、値オブジェクト)
  • DTO(データトランスファーオブジェクト)
  • エンティティ


これらは、EJBの出現により(？)メジャーになった言葉たちです。


DAOは、DB(永続ストア)にアクセスするためのクラスです。
たいてい、VOを引数に受け取って、INSERT、UPDATEを行ったり、
SELECTしてVOやVOのリストを返したりします。


DTOはVOとほぼ同義ですが、微妙に違います。
何が微妙に違うかはメンドクサイので忘れます。


エンティティは、DAO+VO(DTO)のようなペアでDB操作を行わず、
エンティティクラス自体のメソッドにINSERTやSELECTを行うメソッドを定義します。
(SELECTは別のクラスにしたり、staticメソッドにしたりもする)
VO/DTOにDAOの機能も一緒になっちゃったみたいなのが、エンティティです。
EJBのエンティティビーンというやつがエンティティですね。


ちなみに、VOやDTOは、セッタ、ゲッタしか持たなかったりして、
手続き型言語の構造体みたいなので、OOマンセーな人たちは、
これらの構造体チックなクラスは嫌う傾向にあるようです。
オブジェクトは自分で保存するのか別のオブジェクトに保存されるべきか。
保存時は、オブジェクトの内部情報を扱うので自分で保存した方がシックリくるとは思います(JavaのデフォルトのSerializableと、ちょっと違うことするときは、readObject/writeObjectみたいな)。


でもDBがバックエンドのWebアプリケーションを作ってると、
表も裏もDTO風なので(というかマップか)、どうしてもDAO+DTOという設計パターンになりがちです。
まあ、なりがちなものはなりがちな設計が無理がないのかもしれません。
昔は、リクエストをDTOにつめなおす、ResultSetをDTOにつめなおすという、
つまんない上にミスしやすいことをイチイチ全部手書きしてたりしましたが、
最近はリフレクション使ったユーティリティクラスで全部やっちゃうので、
非効率なことは大分なくなりましたし。


ちなみに私は数年前まで、こいつらの言葉をごっちゃにしてました。
なので、save、loadメソッドを持つなんとかVOとかいう変なクラス名のクラスをたくさん作ってしまいました。ごめんなさい。。。まだ間違ってたりして。