ここでは、その他の特記事項について説明します。

Robbie DAOはいわゆるデザインパターンのDAOパターンに沿った実装は行っていません。一般的にDAOパターンを実装することになると、

• DaoFactoryインタフェース
• データストア毎のDaoFactoryクラス
• Daoインタフェース
• データストア毎のDao実装クラス

などを作成する必要があります。また、Daoの実装粒度によりますがテーブル単位でDaoを作成することになると一体幾つのクラスを作成しなければならないのでしょうか。

Robbie DAOの実装の根底には実装しなければならないクラスを極力減らすことによって、工数の減少を行うという根本的な考え方があります。

DAOパターンを紹介した記事で、『データストアがXMLからRDBに変更になってもインタフェースベースだから大丈夫である』というような一文を目にしますが、本当にそのような事態が頻繁に起きるでしょうか？データベース製品が変更になるという場合はあるかもしれませんが、JavaコードとSQLが分離できていればそれでも問題ないはずです。

この結果、Robbie DAOは特定のテーブルに依存しないDAO(XDao、GeneralizedXDao)によってデータベースアクセスを行えるようにすることで工数の減少させています。また、複数テーブルへのデータベースアクセスロジック(または業務ロジック)とデータベースアクセスをカプセル化したい場合には、拡張XDaoを作成するような実装方針としています。

Robbie DAOにはデータベースアクセスに対して以下のような制約事項が存在します。

Robbie DAOにはストアドプロシージャ呼出は実装されていません。これは、ストアドプロシージャ呼出はベンダ独自のAPIに依存することが多いためです。

通常、データベース製品ごとにストアドプロシージャの文法も違うし、使用するデータ型も製品の独自のものになる傾向があります。一般的なJDBC APIで呼出が利用が可能な範囲であればコンポーネント化も可能ですが、それでは業務用件を満たすことは難しいのではないかと判断して、今回は実装を見送りました。

次バージョン以降の課題としたいと考えています。

JDBC3.0ににはLOBデータを抽象化したjava.sql.BLOBとjava.sql.CLOBインタフェースが存在しますが、実際オンメモリでByteデータを操作するような実装が行われることは、あまり現実的ではありません。最もLOBデータを使用する際に多い使用法は、データベースとファイル間でのやりとりでしょう。その場合には、パラメータMap上にバイナリデータを持つのではないため、通常のStringやInteger、Dateなどのデータ型の処理とは互換性が取れません。そのため、LOBの扱いは未対応となっています。