フレームワーク比較
http://d.hatena.ne.jp/t_yano/20081118/1227008018
ポイントとしては作成するアプリによって得意不得意がでるため、その辺は考慮するというところか。
Wicketの考え方はわりと好きだし、Guiceは大好き。でもDBアクセス周りはツールの豊富なサポートがあるJPA使いたいのとトランザクションまわりなどの設定の容易さを優先して考えるとEJB + JPAの組み合わせになってしまうかな。JavaEE6時代は何も考えずにWicket + EJB3.1 + JPA2.0がかなりいける予感。
JPAはJavaSE 7のプロパティ構文対応したときCriteriaが真価を発揮できるかな。文字列や無理やりつけたメソッドを使うのは好きではないからJavaSE 7でぜひとも採用して欲しい。そのときは3.0、JavaEE7あたりになってるだろうか。
でもそのときは覚えなくてはいけないことが多くなりすぎてないか心配。2.0のドラフト時点で大量に命令が追加されて覚えるのが容易ではなくなっていることを考えると、JPA1.0って後から考えると意外といいバランスだったんじゃないかと思えてくる。APIってなんでもそうだけどちょっと物足りないくらいがちょうど良い気がする。ラッパを作る余地が残されているというか。足りないのは各自独自の命令でいいわけだし、それが標準APIというものかと。ただ、ヒントの共通化とかいくつかは最初から欲しいのが多かったけど。
ただ
プログラム的にLAZY/EAGER を変換する方法はないっぽい。
ってのはないんじゃないかな。JPAでは設定をLAZYにしておいて、取得時にIN設定だったか（記憶が曖昧なので後で調べなおす）するとLAZYでもEAGERでとってきた記憶がある。気のせいかもしれない。
あとJPAは@PersistenceContextでDIできてすぐ使えるのと同様の環境があるのなら@Resourceでデータソースをインジェクトできるので、ネイティブSQL云々はそっちでやればよいとわりきると楽。例えばDBUtilを使用してJavaSE5構文に対応したクラスを作るとものすごーく楽。
JPQLは独自というよりEJBQLからの派生。というかほぼ同じ。
更新操作は他のものと変わるようには見えないなぁ。むしろ変更があったフィールドだけを適切に更新してくれるので（Toplink、EclipseLink、OpenJPAにて確認済み）キーや更新比較用のBeanを用意しない分優れていると思う。管理状態かどうかはトランザクションをコンテナ管理のみにしてしまえば問題はない。
トランザクションは無条件でJTA必須として考えたほうがいいんじゃないかな。glassfishなどの真っ当なアプリケーションサーバーにデプロイするとJTA以外はデプロイ時にはねられたりするし。
