僕がSQLを意識しても良いと思う理由(わけ)
わたしは、以前からO/RマッパーはSQLを意識しても良いとおもっています。
今もその気持ちには変わりはありません。しかしナカナカ同意は頂けないのが事実です。
だからと言って「そーすか、やっぱ、そーすか、じゃSQLを隠ぺいしましょ」と言ってはいけないと思うので、何故、私がO/RマッパーはSQLを意識して良いとおもうのか！自分の意見を聞いてもらわなければいけないのだと気付きました。遅きに逸した感は否めませんが、ここまで書いたので賜ります、平にご容赦を....m(＿＿)m
私が何故、O/RマッパーはSQLを意識しても良い思うかの理由は、100%O/Mマッパーの機能だけでシステムが開発出来ないからです。
そのため、少なからずSQLが顔を出してきます。。。顔の出し方は様々ですが、ネイティブSQLを記述する可能性はかなり高いと思います。
中には全部Viewで全て済むよ（＾＾）というシステムもあるかもしれませんが、規模が大きいシステムであればかなりの高確率でネイティブSQLが顔を出してきます。
＊個人的に「全てViewで全て済むよ」というシステムは単純な照会がメインのシステムだと思っている。
それが証拠に、新人教育の際にSQLを教えている会社は多いのではないでしょうか？(言いすぎ？)
開発言語は様々でしょうが、SQLは高確率で利用されます。。。
ある意味SQLは、開発者にとって共通言語なのではないかと思っています...またまた言いすぎ（＾＾；）
開発言語がかわっても高確率でSQLは利用されます。と思ってます。
という前提が成り立つとして、O/RマッパーとネイティブSQLがかけなはれていると2倍の学習量になるわけです。
仮にSQLを意識しないO/Rマッパーであった場合は、CriteriaがSQLをラップするかSQLと異なる方法で記述するかの2通り考えられます。
その典型的な例としてJPA2.0のCriteriaがあげられます。
JPA2.0のCriteriaは比較的ネイティブSQLに近いのですが、それでも記述の仕方がSQLと異なるため変換が必要になります。
詳しくは「日本人だからなのか？それとも自分の問題か？」を参照してください。
JPA2.0の場合は、ネイティブSQLの「where A and (B and C or D and E)」の記述が下記の様になります。
[JPA2.0で実装した例]
cq.select(r).where(qb.between(r.get(Customer_.customerId), 1,10000),
qb.or(qb.equal(r.get(Customer_.city), "Dearborn"),
qb.like(r.get(Customer_.city), "%New%")),
qb.isNotNull(r.get(Customer_.addressline1)));
詳細は以下のurlを参照してください。
上記をみても分かる通り、JPA2.0のCriteriaは比較的ネイティブSQLに近いにも関わらず条件文の記述の仕方が、まったく異なります。
DRYを持ち出すと、それは違うと指摘を受けるのを承知で書くと思考のDRYに反していると思います。
同じ内容で、テーブルを参照するのに思考が全く異なる記述の仕方はDRYでは無い＞＜
ハアハア、かなりエキサイティングしましたが、これが私のO/RマッパーはSQLを意識しても良いと思う理由なのです。。。
と言う事で、EzJDBC(EzJRAP)はネイティブSQLに近いっすよ...(＾＾)
って結局自己アピールかよっ…（￣口￣ι）
