DAOって結局なんだ？未解決のException。
結局今日は、Actionにベタ書きしていたSQL部分を切り出して、DAOに分離させるっぽい事にチャレンジ。
まず、抽象クラスとして、コネクションをはるところ、executeQuery()、executeUpdate()、ロールバック、コネクションやステートメントのクローズを準備。
準備といっても、Google先生に教えてもらったサイトからちょいと拝借してカスタマイズ。
で。
ここから先は、どういう単位で継承クラスを準備するか。
この部分は、いろいろ議論が及ぶところですが、正直まだよく分かんない。。。
Entity単位に準備すれば良さそう、というのはなんとなくわかります。
ていうか、そもそもEntityってどういう単位として考えるか。
が、勘違いしてはいけないのが、画面＝Entityではないということ。
そして、TABLE＝Entityでもないということ。
と、今は考えています。
きっと似たような問い合わせをする画面が複数あったりするわけですよ。
画面単位で用意すると、似たようなSQL文があちこちのDAOに散らばる事になります。
今思いついた事ですが、ある程度汎用的な問いあわせ…つまり、AというテーブルとBというテーブルを結合したCというViewっぽいものを、全カラム取り出すEntityをざっくりと用意します、と。
これを、必要に応じて各Actionから利用する。
これなら、Aというテーブルのa、bのカラムを利用するAction、ａ,cのカラムを利用するActionがあるとすると、同じEntityとみる事が出来ます。
テーブルが複数になっても、Viewとしてみれば問題ないでしょう。
で、今日は結局Actionから分離させる、DAOの抽象クラスを作って、分離させた部分を継承クラスへ実装する、にとどまりました。
つまり、DAOの継承クラスの中に全部放り込んじゃいました（汗
まぁ、アプリケーションの規模によってはこういうのもありじゃないかと思いますが、ソースコードが500行近くになってきたので、そろそろ分割した方がいいかと思う今日この頃であります。
—————-
さて、もうひとつ未解決があります。
例外クラスのExceptionとSQLExceptionを、それぞれをそれぞれの独自例外を用いてActionクラスでcatchさせるには…？
単純に考えたのが、Actionクラスのexecute()内を全てtry～catchで囲ってやって、SQLException→Exceptionの順にcatchしてや…。。。。
あれ、なんかおかしくないかな？
SQLExceptionは、基本的にはDAOクラスで発生するので、DAOクラスでcatchしたら、独自例外にスローする。
DAOを利用しているActionクラスでは、独自例外をcatchして画面遷移に利用できます。
どっこい、Exceptionはあちこちで発生…というか、全ての検査例外の親クラスなのでActionクラスで発生したExceptionで独自例外に渡してやるっっていっても、Actionクラスからはどこにスローするの？？？
スローできたとして、何が処理するの？
んー、tomcatかしら。
struts-configに、global-exceptionを定義できるので、Exceptionをcatchして独自例外がスローしたものは、こいつがひらってくれるのか。
でも、Exceptionよりも先に発生したSQLExceptionは、スローさせてきた結果、親クラスであるExceptionに持っていかれちゃったりしないのか。
DAO、独自例外、いずれももう少し試してみるだけの時間もなく時間切れになりそうだなぁ。
2010年6月29日 23:44 
By たろー, 2010年6月30日 @ 12:38
DAOの考え方は色々あるので、私なんか未だに悩むことが多いです
結局、既存のやり方に合わせたり、
既存がなければ、自分があとからメンテしやすいような作りにしたり、処理がどのように転がってもマズいことにならないようなセーフティな作りにしたり、今流行りのデザインパターンのなんとかパターンにしてみたり。
あとは、DBMSの視点かなぁ？
どのようなコードにすればパフォーマンスが向上するか？とか。
By mika-chan, 2010年6月30日 @ 21:42
＞たろーさん
なんとか無事に最終課題発表が終わりました。
決まったやり方ってのはないようですね
後の事を考え過ぎて汎用的に作ったり、デザインパターンにはまりすぎると、結果的に何かにしわ寄せがきそうですね。後のメンテナンスやパフォーマンスとか。
DMBSの視点ですか。
確かに、MySQLとかだと複雑な結合を単位とするDAOとかだとパフォーマンス悪そうですよね。
まぁ、いろいろ悩みながらですわ。