最近急にJPAをいじりだして、どうにもうまく使えなくてORMの行く末をぼんやりと考えているのだけれども。
なんでそんなにもSQLを隠蔽しようとしたがるのだろうか？
もちろん、JPA環境でSQLが使えない訳ではない。訳ではないけど、下手すると結果がオブジェクト型の2次元配列で受け取らなければならない。これでいいのだろうか。あとSQLについてはJavaの世界で単なる文字列として扱うため堅牢な型システムのあるJavaにあってよけいな不安要素を多分に持ち込む要因であるし、IDEの支援をこれでもかというほど受けられるJava環境にあって結局はただの文字列でしかないSQLを業務ロジックに応じてくっつけたり切り離したりして、最終的に実行してみたらDBMS依存の記法の誤りとかであっさりHTTP 500みたいな、まぁ結構厄介なものではある。でもSQL自体がそれほど難しいかと言えばそうではないし、既存のテーブル設計ベースでマッピングするフレームワークでは結局テーブルの情報をそのままの形のBeanのような形にしかマッピングできない（・・・厳密には違うが、そこに確固たるプログラミングモデルが存在しているように見えない。そういう使い方にも対応できるようになっているよ、というか）。
結局ORMってなにをやりたいんだろう？極端な理想を言ってしまえば、メモリが無限で不揮発でかつ十分高速ならば、ストアする必要もORMなんかが発明される必要も無かったのだろうけど、実際にはメモリは高速だけど要領の制限が強くて揮発性だ。その辺をアプリケーションからなるべく意識せずロード／ストアで切るようにいろいろ頑張っているんだけど、そう考えると結局重要なのは全体のオブジェクトグラフのうち、とりあえずメモリの容量分しかメモリにはのせられ無い訳だから、全体のオブジェクトグラフから「ここだけ」という範囲を指定して持ってくる事になる。これはテーブル的にこのテーブルとこのテーブルと・・・という範囲のしぼり方が必要だし、この行からこの行までといった絞り方も必要だ。JPAはこれに対してレイトバインディングで挑む格好なんだけど、それをONにするかOFFにするかしかできない。アプリケーションの各ビジネスロジックが処理を行う際に、自分の必要な範囲のオブジェクトを条件にして引っ張れればいいのだが、これはビジネスロジック個別で異なるものなので、全体でONとかOFFとかで対応できるもんじゃないかな。その点に付いてJPAの設計者はどう考えているのだろうなあ。あとなんかちまちま特定のオブジェクト構造を作り上げていくだけのコードを結構書いている気がするのだけどこれはこれでいいのですかね。よくわからない。