相次いでリリースされました。
http://tomcat.apache.org/
どちらも、バグフィックスと依存ライブラリや
同梱するEclipse JDT コンパイラのバージョンアップが中心です。
最近仕事で使っています。
実際に仕事で使うようになるまで、iBatisを詳しくは知りませんでした。
「SQLを直接指定できるORマッピングフレームワーク」
「Apache iBatis Projectで開発されているOSS」
という程度の認識でした。
調べてみると、O/Rマッピングフレームワークとしての機能はひととおり備えています。
が・・・しかし・・・
こりゃ、O/Rマッピングフレームワークと言うよりは
SQL/Oマッピングフレームワークですね。
「オブジェクトの永続化」という考え方は薄く、
「SQL文をオブジェクトにマッピングする」というイメージ。
iBatisではマッピングの対象は、テーブルやカラムではなく、あくまでSQL文です。
HibernateやJPAでは、エンティティオブジェクトとテーブル、
プロパティとカラムを関連づけていきます。
それに対してiBatisでは、エンティティオブジェクトとSQL文を関連づけます。
テーブルありきの、完全にデータベースドリブンなボトムアップアプローチ。
「オブジェクトを永続化する」というアプローチではありません。
関連やカスケード処理、Lazy Loading機能は弱く、SQLで何とかする感じですね。
SQL/Oマッピングフレームワークというアプローチは
オブジェクト指向としては美しくないかもしれませんが、
とても現実的だと捉えるのもありかと思います。
で、このiBatisですがO/Rマッピング（というかSQL/Oマッピング）フレームワークと
DAOフレームワークが用意されていますが、最新バージョン（2.3.0）では
DAOフレームワークは非推奨となり、
SpringのiBatis連係機能を利用することが推奨されています。
ところが・・・
Apache iBatis Projectからは、DBスキーマ情報からエンティティオブジェクトとDAOを
自動生成するツール「Abator」がリリースされていますが、
このDAOは非推奨なDAOフレームワークにしか対応していません。
ということで、DBスキーマ情報からエンティティオブジェクトと
DAOと設定ファイル類を自動生成するツールを自作しています。
テンプレートエンジンには FreeMarker を使いました。
Antタスクとして作成したので、
コマンドラインからでもEclipseからでもNetBeansからでも利用できます。
シンプルなCRUDは全部自動生成しました。
どんな単純なCRUDでも全部SQL文を書かなくてはならないという
iBatisの欠点というか面倒くさい点を克服できます。
Genericsを利用した、よいDAOができたと自画自賛です（＾＾；
内部的にはインスタンス管理とDB接続管理がラクなのでSpringを使いました。
Webアプリケーションではないところで使うのは初めてでしたが、
改めて依存オブジェクトの外部注入の素晴らしさを実感しています。
他のファイルを生成するような機能を追加するときも、
既存のコードを修正せずに機能追加できます。
ただ、個人的には実装クラスとインタフェースを分離する必要が無いと感じる
オブジェクトも多いのですが、「Springで管理するクラスはインタフェースが分離されている」
というお作法というか、暗黙の了解みたいなものがあるので
個人的には疑問を感じつつ渋々インタフェースと実装クラスに分けたクラスが多いです。
実装クラスとインタフェースが分かれていないと何か特別な理由があるのか？
と勘ぐられそうなほど常識化している勢いですからね・・・・
この常識は何とかしたいものです。
必要以上に作成・管理しなければいけないファイルを増やす必要など無いはずですから。
Atom Feeds 
