DAO、DTO、Entity（VO）の整理。

なんとか最終課題の提出とプレゼンが終わりました。
合否判定はずっと先ですが…。
とりあえずこれで講師への技術質問が解禁になったので、気になってた事を軽く整理してもらいました。

まず、図というか、こんな感じで層を分けるとします。

Actionクラス　｜　ビジネスロジックのクラス　｜　DAO　｜　DB

Actionクラスから左側は書いてませんがStrutsです。
今の段階ではビジネスロジックをActionクラスに書いてます。
上記の図に従うと、Actionクラスがビジネスロジックに依存しない形で実装する事になります。
同様に、ビジネスロジックとDAOも依存関係がないようにします。
こうすることで、フロント側に変更がかかった場合、つまり、Strutsじゃなくなった時でも手が打ちやすい。
同様に、DB周りが変わった場合は、DAOクラスに手を入れるだけでよい事になります。
なるほど、なるほど。

で、ここで登場するのが、各クラス間のオブジェクトのやりとり、つまりデータのやりとりをするためのオブジェクトが必要です。
その型にあたるものがEntity（ValueObject）、DTO。
型というと漠然としていますが、DB等からSELECTしてくると、複数レコード取得したりします。
この時の１レコード分のデータを詰めるものがDTO。
DTOには、DBからSELECTしてくる項目を定義している感じです。
複数レコード取得してくる場合は、Listにぶち込むわけですな。
一方で、Entity（VO）は、Actionとビジネスロジックの間でやりとりされるもので、セッションやリクエストスコープに詰めるもの、と考えるようです。

Action　<=>　ビジネスロジック　：　Entity(VO)
DAO　<=>　DB　：　DTO

あれ、「ビジネスロジック　<=>　DAO」は何だっけ？？？

まぁ、あれだ。
より生データに近いものは、表示するために遠いデータ。
たとえば金額とかだったらint型でDBに入ってるので、DTOにはint型で入ってる。
これを表示するために近い形で持つEntityでは、金額のフォーマット（￥999,999）とかで、Stringで入ってたりするのかな。
このあたりの変換や計算をするのはビジネスロジックに任せる。
Actionクラスは結局ビジネスロジックが処理した結果を元に、画面遷移やスコープに詰めるだけって事だね。

ひーこら言いながら取り組んだ課題だったけど、ここまでの考え方を理解した瞬間、作り直したい感が満載でしたorz.gif

まぁ、今の知識ではActionクラスとビジネスロジックとの依存関係を断ち切る事ができないのも分かったんですけどね。
これを解決するために、DIコンテナのお話が出てくるようなんで、またお勉強です。
今時点では、Actionクラスのexecute()内には

コレクション型<何某> hehe　＝　new コレクション型<何某>（）；
ビジネスロジック型　hoge　＝　new　ビジネスロジック型（）；
hehe = hoge.getFuga()；
if( hehe == null){
　mapping.エラーページ
}else{
　httpsession.setAttribute(”HEHE”,hehe)；
　mapping.正解のページ
}

みたいな事をするのが精いっぱいですかな。

blogランキング参加中。クリックよろしく！！→にほんブログ村 バイクブログへ

categories お仕事、技術 | mika-chan | datetime 2010年6月30日 23:33

  • By たろー, 2010年7月2日 @ 12:19

    ぅぁ本格的 :a4_sweat01:
    そこまでやってんのか。

    変換はDXOかな？

  • By mika-chan, 2010年7月3日 @ 17:24

    ＞たろーさん
    今回の研修そのものの内容ではないんですよ。
    たまたま僕が質問しただけの話なので。

    一部機能は、理想通りに実装し直してみましたが、コード量とクラスの数が膨れました。
    これが現実というやつですな。
    うまいこと、DTOとVOが持つパラメータ名をそろえてあげて、BeanUtils使えば多少は抑えられるようですが。。。

    DXOのお話は出ませんでしたねぇ。

Other Links to this Post

WordPress Themes