DAOの勘所。

毎度、オブジェクト指向にどっぷりな生活を過ごしています。

先週後半から、最終課題に突入しています。
一応、習得内容から実装するのですが…講義の内容と課題の内容がぶっ飛んでます。
１、２教えたから、残りの９は自分で考える、もしくはGoogle先生によろしく！なんていう状況です。
しかも最終課題中は、技術的な質問や周りの人との相談もNGなんですよね。
まぁ、こういう自力でしんどい思いをするからこそつく力もあるんでしょうけども。

で、つい先ほど力尽きて帰宅したのですが。
実装できてないのがDAO。
Strutsを使ってますが、現状Actionに直接SQL書いちゃってます。
考え方そのものは理解できるのですが、実用アプリ実装レベルになると、手が止まるんです。
DAOの作成単位とか、いまいちピンとこないのです。
そもそも研修内で触れてないところだし！
それってどーなん！？

さて。
極端な話、SELECTのDAO、UPDATE、DELETEのDAOの２つだけでもいいのか？
ステートメントを渡して、excuteQuesry()か、executeUpdate()のどっちかを実行するだけ。
あぁ、これじゃだめだ。
たとえば、極端な話特殊なDBに変更になった場合や、テキストファイルなんかになったら改修箇所大杉。

DAOFactoryみたいなクラスを作って、問い合わせ単位でアクセサメソッド作る方がいいか。
問い合わせ、更新、削除対象となるオブジェクトの参照値を渡してやる。
問い合わせの場合は、戻り値は要考慮。

DAOクラスでSQLExceptionが発生した場合はどうなるのか。
他の参加メンバーが、FilterでSQLExceptionをcatchしてやろうとしていました。
どっこい、ActionクラスからSQLExceptionをスローしても、いろいろ経路を通ってくる間に、ServletExceptionとかExceptionになってしまうとの事。
上位層のビジネスロジックにまでスローしないようにするには、独自例外を作ってそいつにスローするって事になるわけですか。
なるほど。
それで課題の中に「SQLExceptionを継承した独自例外を作る事」ってーのがあるんだな。

ていうか、明日しかないんですが。
現状動いているので、手を入れたくないんだよなぁ。
データアクセスって結構肝じゃないか。
プレゼン直前に動かなくなるって、ありえねーしなぁ。

ってか、考えるなら会社でやれっつーの。
帰ってきて服脱ぎ散らかしたまま、布団に寝そべってノートPCつついてググってるわけで。
まぁ自宅だからリラックスして頭が回るってのもあるんだけどね。
なんていうか、もう一日だけ余分に納得いくもの作れそうなんだけどなぁ。

まぁ、Strutsも枯れた（熟成された）フレームワークなんだけど、決して効率のいいものじゃないってことは分かったかな。