学習用ORマッパー「EzJDBC」の作成

賛否両論ある「S2JDBC」ですが、個人的には、とても好みのORMです。
なので、自作ORM(EzDao)をブラッシュアップし、学習用にS2JDBC風のORMを作成してみました。


流れるようなインターフェース（fluent interface）


EzJDBCで「CUSTOMER」テーブルと「ORDER」テーブルを結合した検索例を見てみましょう。

　　// メインテーブルの顧客テーブル情報インスタンスを生成します。
　　CUSTOMER _CUSTOMER = new CUSTOMER();
　　// CUSTOMERテーブルとORDERテーブルを結合し抽出条件に一致した結果を取得します。
　　List result = new EzJDBC().from(_CUSTOMER)
　　　　　　　　　　　　　　　.join(_CUSTOMER._ORDER)
　　　　　　　　　　　　　　　.where(_CUSTOMER.ID.in(1, 2, 3))
　　　　　　　　　　　　　　　.orderBy()
　　　　　　　　　　　　　　　　.asc(_CUSTOMER.ID)
　　　　　　　　　　　　　　　.find(Customer.class);

追記：「CUSTOMER」テーブルと「ORDER」テーブルを結合は、下記の記述でもＯＫです。
List result = new EzJDBC().from(_CUSTOMER._ORDER).where ...

EzJDBCの開発コンセプト


EzJDBCは、「そのまま食べても美味しい」「自分なりに味付けすると、もっと美味しい」をコンセプトに開発されたORマッパーです。
いわゆる「早い・安い・うまい & アレンジＯＫ」の“○牛レトルトパック方式”のORマッパーなのです。
翻訳すると「直接利用しても便利」「独自にラップしても便利」って事です。


EzJDBCを、そのまま利用すると、SQLがあちらこちらに散在し、テーブル変更の時に、問題になるかと思われがちですが、ナンノその！　タイプセーフなEzJDBCは、テーブル変更時にこそ、その威力を発揮します。


また、EzJDBCを利用して「Daoパターン」を実装するのも“Super Easy(超簡単)“です。
下記に、EzJDBCを利用して、Daoパターンを実装した例を記述します。
＊EzJDBCでは、Dao作成用scaffoldも用意されています（がマニュアルで記述しても全く手間になりません）。

EzJDBCを利用してDaoクラスを実装した例

public class CustomerDao {

　　　// メインテーブルの顧客テーブル情報インスタンスを生成
　　　protected CUSTOMER _CUSTOMER = new CUSTOMER();

　　　// CUSTOMERテーブルとORDERテーブルを結合したEzJDBCインスタンスを生成。
　　　protected EzJDBC jdbc = new EzJDBC().from(_CUSTOMER)
　　　　　　　　　　　　　　　　　　.join(_CUSTOMER._ORDER)
　　　　　　　　　　　　　　　　　　.orderBy().asc(_CUSTOMER.ID);

　　// 指定したIDと一致した顧客データListを取得します。
　　　protected List getCustomerListById(String id1, String id2) {
　　　　　　return jdbc.where(_CUSTOMER.ID.in(id1, id2)).find(Customer.class);
　　　}
}

本当に「Super Easy(超簡単)」なのが理解して頂けると思います。継承なんかしなくても良いのです。
抽出条件(並び順)は、呼び出される毎にクリアされますので、１つのEzJDBCを使いまわす事が可能です。


【補足】Daoパターンに、こだわらないのであれば。。。　

EzJDBCは、独自にラップせずに、直接利用しても全く問題ありません。
それどころか、タイプセーフである最大のメリットは、直接利用することにあります。
いわゆるDAO(Data Access Object)クラスが不要となることが、最大のメリットになるのです。

取得したいデータは、EzJDBCのSQL自動生成利用して、直接取得すれば良いのです。
この違い(DAOの有無)は、開発者にとって大きなメリットになります。
何故なら、DAOが無くなる事により、思考を中断せずに開発を続ける事が可能になるためです。

何故DAOが無いと思考を中断せずに開発できるの？

具体的な例として、ロジックを構築中に、あるテーブルのデータが必要となったと仮定しましょう。
この時、開発者は、対象となるテーブルのDaoクラスを参照し、利用可能なメソッドを検索します。
この時点で、現在作成中のロジックの思考が停止します。

また、適当なメソッドが存在しなかった場合は最悪(T-T)です。
他の開発者に必要とする機能の存在有無を確認する事になります。その結果、やはり存在しなかった場合は、誰がその機能を実装するのかを、リーダーやプロジェクト・マネージャーに確認する作業が発生してしまいます。
これでは、完全に本筋ロジックの思考は停止してしまいます。

EzJDBC(のSQL自動生成機能)が、この問題を全て解決してくれます。

個々のプロジェクトで「何故、Daoパターンが必要なのか」を考えてみると良いかもしれません。
注意：DAOの利用が悪いわけではありません。開発前に80%のメソッドが実装できれば良いパターンです。

タイプセーフを可能にする「テーブル定義クラス」


つづく…