[Hibernate] O/Rマッパーって、ほんとに必要？

Oakbow — Thu, 12 Aug 2010 23:43:00 GMT

O/Rマッパー。
半ば常識、使って当たり前みたいに言われているフレームワーク。
多分この分野で一番元気なのはJavaだと思うんだけど、Javaに限っても結構な数があります。

私の初O/RマッパーはHibernateでした。
全体の開発期間は2年、実装からリリースまでの期間は1年半という、中規模程度のWebアプリケーションで採用。
実際にはHibernateを素で触ることはほとんどなく、SpringのHibernateサポート機能を通じて操作しています。

初見の感想は、
「軍手二枚重ねにした上で、箸で皿に盛られた豆つまんでる様な感覚」
でした。
素手で掴めばいいだろうと。

Hibernateを含めたO/Rマッパーの情報を漁ると、ほとんどが礼賛、という状況です。
個人的には不思議でなりません。
SQL覚えてなくていいとか分からなくてもいいなんて書いてある場合は、嘘はやめろとさえ思います。
デバッグモードなりでコンソールにSQLを吐かせて、意図通りのクエリが発行されているか確認するのは必須でしょう。

Javaのように、オブジェクトありきの言語では、実際O/Rマッパーは必要だと思います。
オブジェクトへのマッピングを行うフレームワーク、という存在自体は。

でも、CriteriaやHQLなどの、SQLを自動発行できる仕組みはそれほど必要だろうか？と思ってしまいます。

もちろんあれば便利です。
SQLを組むときとJavaでプログラミングしているとき、私は頭の中の思考回路というか、ロジックの組み方というか、頭の回転方法自体がちょっと違っています。
しばらくJavaばかり触っていて、しばらくぶりにSQLを書くときなどは少々頭の切り替えが必要になります。
Criteriaを使うのであれば、Java的思考からSQL的思考に切り替えずに組むことが出来ます。
まあ、Criteria組み終えたらDAOをテスト実行して発行されるクエリを確認するので、そこで切り替えは必要にはなるのですけれど。

こういう感覚が一般的なものなのか私くらいのものなのか分かりませんが、JavaよりSQLの経験の方が長く、よりDBに親しんでいる私でさえこう感じるので、世のJavaプログラマーがJava上でのプログラムで完結させたくなる気持ちは分からないでもありません。
でも、私はこれ、RDBMSを使う時点で必要となる苦労だと思ってるんですよね。

Hibernate、決して簡単ではありません。
Hibernateトラブルシューティング
こちらの第1回と第2回に説明されている内容くらいは基本として踏まえていないとまともに使えないと思います。
さもないと、「動くけど使い物にならない」システムになりかねません。
テスト工程で様々な問題が発覚し、リリース直前まで慌てることになります。
･･･というかなりました。

こういった意見への反論はたいてい、「それはHibernateへの理解が足らないから」というもので、実際その通りだと思います。
逆に言うとそれだけ学習コストの高い代物で、1年程度のプロジェクトを１件こなして初級に到達できるように感じています。
自在に操れるようになるまで案件いくつこなせばいいんでしょうか？
少なくとも中級程度には使える人がプロジェクトメンバーにいないと、とても採用できないくらい難しいと感じています。

O/Rマッパーの謳い文句にはよく、「90%のSQLを自動発行することで効率化」というものがあります。
個人的に90%は眉唾ですが、少なくとも残り10%は手書きのSQLが必要であることを認めていることになります。
量にして10%ですが、当然そのクエリは自動発行では対応できないような複雑なものだったり、パフォーマンスを要求されるものだったりするわけです。
おそらく、RDBMSの実行計画とにらめっこしてクエリを書くことが出来る、中級以上のSQL熟練者が必要になるんじゃないでしょうか。

O/Rマッパーが自動発行してくれる90%のSQLは単純で組むのが簡単なものがほとんどなわけで。
あれ？
Hibernate使うならHibernate熟練者が必要だけど、どっちにしろSQLの熟練者もいるよね？
最初からその人に簡単な方までやってもらえばいいんじゃね？
数は多くて正直めんどくさいけど、書くのに時間はかからないわけで。

もちろんホンモノの世のHibernate熟練者はSQL覚えなくていいなんてタワゴト吐いたりはしてないでしょうし、SQL熟練者を兼ねている可能性は高いです。
でも、Hibernate熟練者とSQL熟練者、探すならどっちが楽でしょうね？
彼らが技術リーダー的立場になって、他のプロジェクトメンバーにノウハウ伝授しつつスキルレベルを向上させながら開発していく、なんてことも多いと思いますが、どっちが習得しやすくて、以後のプロジェクトでもより活用しやすいでしょうね？

Hibernateは現状、JavaのO/Rマッパーの中では最も評価が高く、おそらく採用実績も多いと思いますが、10年後には存在しているかすら怪しいです。
RDBMSは10年後も現役でしょうし、今のSQLの知識は変わらず活きると思いますけどね。
KVSって対抗馬がいるんで今より地位は下がる可能性は結構高いとは思いますけれど。

「軍手二枚重ねにした上で、箸で皿に盛られた豆つまんでる様な感覚」
Hibernateを触り始めてもう二年になりますが、この感覚はあまり変わりません。
さすがに慣れたので、軍手二枚重ねが一枚になったくらいではありますけれど。
「動くけど使い物にならない」ところをNative Queryに書き換えまくり（HQLはハナから考慮の対象外）ましたが、もっと早くからCriteriaの仕様箇所を限定すべきだった、という思いが強いです。
書き換えた方がよい箇所はまだまだあるんですが、優先度や工数、金銭的な問題で手を出せないという現実がありまして。
技術者的感覚では手を出したくてたまらないところですが、運用に入っているとそうもいきません。

Hibernateがもたらしたものはなにか？
純粋な意味でのO/Rマッピングでは助けてくれました。
オブジェクトへのマッピングを手作業でやっていてはとても大変だったでしょう。
でも、Natige Queryへの書き換えを余儀なくされた分、楽させてもらった部分、効率化の恩恵は軽く吹っ飛んでいます。
Native Queryへの書き換え（できればストアドへの書き換え）を行いたい部分は要するに使えはするけど重ったるいとか、もっさりしてるとかそういう機能な訳でして。
そういった部分で顧客の心象を悪くしているだろうなーとか思ったりもする訳で。

私自身はフルストアドを真面目に提案したくらいSQL寄りな考え方なので割り引いてもらう必要があるとは思いますが、Hibernateがもたらした効率化は軽くマイナスになっています。
O/Rマッパーというものを経験できたという意味で私の経歴にはプラスになっているのですが、こと採用プロジェクトにかんしてはマイナスです。
使わなかった方がマシか、発行クエリをすべてNative Queryにしてしまうか、まあコレクションじゃないオブジェクトに対する単純なCRUD操作くらいに限定すべきだった、という感想です。
それもまた、プロジェクトが終わったあと、ある意味神の視点からじゃないと出せない都合のいい感想ですけれど。

まあ私が見た痛い目は、対象となるデータ量の見積もりが甘かったってことに尽きるんですけどね。
バッチ処理やバルク処理に弱いとは聞いてたけど、四日かかる処理が15分に短縮できたとかどこの世界ですかって話になる訳で。

というわけで、私自身は今後Hibernateを他のプロジェクトで使うことはないと思います。
iBatisとかS2JDBCとかS2DAOに興味はありますけどね。
正直アプリケーションが吐くクエリは完全に管理したいので、フルストアドが理想なのは変わりません。
メンバーの担当分野を層で分けるやり方って、あんまり一般的じゃないのかなあ。

Hibernateは％メタ文字をエスケープしてくれない

Oakbow — Fri, 24 Oct 2008 21:30:00 GMT

Hibernateで、クライテリア使って開発してます。

あいまい検索とか俗に言われるSQLでのlike句では、

Restrictions.like("フィールド名", "文字列", MatchMode)

って書き方で実現できます。

MatchModeってのは前方一致とか後方一致の指定のための列挙型です。

DB内の文字列検索とかには普通に使うだろうと思います。

が、ユーザーの入力文字列が入るだろう文字列部分に % あたりが入ってても、Hibernateはエスケープなどはやってくれず、そのままクエリ投げてしまいます。

つまり、入力フォームのヴァリデーションなどで入力必須とかにして全件一致を防いだつもりでいても、全件一致のクエリが投げられるわけで。

個人的には　えー、なにこれ？　って仕様です。バグかと思うくらいの。

エスケープありとなしが用意されているとかなら分かるんですけど、どうやらなさそうだし。

あんまり騒がれてる様子もないけど、みんなどうしてるんだろ？

うちとこでは、フレームワーク全般を担当しているプロジェクトメンバーさんが、%や_などのメタ文字をエスケープしてくれるメソッドを追加してくれました。

プロジェクト内では Restrictions.like を避けて、追加したメソッドを使うことで解決してます。