O/Rマッピングとか使わないでサクッとjavaでDBアプリ

最近のやつでiBATISを使ってみましたが・・・
確かにHibernateに比べれば超楽ですが、
習得に１日はかかる・・・
（優秀な人ならHibernateくらい１日でマスターできるかもですね・・・）

結論：
やっぱりDbUtilsを使うのがベスト


という結論に落ち着いててなんですが、
ちょっと良かったのがiBATISを使うEclipseプラグイン、
iBATOR（abator）
↑iBATISの定義ファイル（xml）とかBeanとかを、実際のDBに接続して作ってくれます。

最初の半日～１日かけて、iBATIS+iBATORの環境を作ってしまえば、
「テーブル単位でのCRUDクラス」はほぼ自動で作成・更新できるようになります。


むしろ、iBATORを使わない場合、iBATISはちょっとねー、、、

「Youすぐやり方忘れちゃうんじゃない？」
みたいかもよ。いくら簡単とはいえ、結局のところなんかxml書かなきゃだし。


ここでちょっとトラブル：
iBATORで、AccessファイルをODBC経由で使ってみたら、
テーブル定義の主キーが拾えないようです。
（↑急遽、JavaDB（Derby）を使いました・・・）

プロトタイプ作るのにAcccessのMDBは便利なんですが・・・iBATORここでも減点。


残る問題は、

　・複数表を結合してselect（条件したりorder byしたり）する場合
　・複数表の同時更新（トランザクションというやつ。外部キーなんかもあったりして）

なんですが、

ここでDbUtilsをちょっと改造（継承）して使うことにしました。
http://commons.apache.org/dbutils/examples.html
http://blog.utils.jp/2008/04/dbutils.html

DbUtilsの列名の解釈を、デフォルトのCOLUMN_NAME表記 -> ColumnNameに変更です。
・・・ハンガリアン記法って言うんですね。

いちにぃ　ハンガリアン♪
ハンガリアン♪ ハンガリアン♪ ハソガリアン♪



これによって、
iBATORが自動で作ってくれたBeanクラスをDbUtilsの結果受けに使えるということ、、、とは、

・結合表のselectはDbUtilsで作って、
・その受けBeanはiBATORが作ってくれたBeanを

そのまま or 継承して作るとラクになるかもってことです。

DbUtilsは永久に不滅ポイント

ちなみに今回はStruts2の中で使ってみました。
Struts2はかなりおススメ。
 

テーブル定義を変えた時の手間についてひとこと。

変更箇所が多そうですが、要は見落としがなければ良いってことなので、以下の手順となります。
（変更箇所が多すぎる場合は、そもそもちゃんとしたO/Rマッパーを使うべきだと思います）

　・iBATISの定義ファイルを修正。 -> iBATOR実行　（作業は瞬殺。Beanクラスが更新されます）
　・Beanが変更されるため、赤く（Eclipse）なったところを修正
　・DbUtilsはテーブル名でgrepしてSQL修正。　（これは仕方ありません。注意深く更新します）

そんな感じです。面倒なのはDbUtils（主に結合表）の更新だけで、
Bean（getter/setter）クラスをいちいち修正しなくて良いんで、結構楽ですよ。


そうかと思うとjspは手で修正なんだよねー
なんとかならんかねjsp（というかタグ）