最近はてな障害情報が出ることが多すぎる．長文何度も消えた．プレビューは鬼門．
JPA Hibernateの使いどころ
愚直なシンプルさを求めるか
JPAに限らずフレームワークやライブラリといった環境にあわせた開発をするのは当たり前なんじゃないの？よくJavaなのにVBやCOBOLやCみたいな思想で書かれてるとかを非難するのと同じように．
View層だってStrutsの考え方でJSFを扱ったら大変なことになると思うし，JSFの考え方でStrutsを触っても大変なことになると思う．JPAならばRDBというもっとも基本となるところに強く影響するため，View層の思想よりうける影響はでかい．
JPAは数あるO/Rマッパの中でも非常にシンプルなものだと思う．DBに関連をつけておいて，Entityクラスはすべて自動生成．もしくはEntityクラスからDBを自動生成．テーブルのカラム情報はそのままプロパティになる．
元々CMP Entity Beanをベースに非管理状態をJava Beansとしてポータブルにしたという経緯があるため，Entityクラスにはロジックを書いてはいけないとも思う．そもそもテーブルにはロジックはないし，Entityクラスは自動生成に期待するため，追加で書いたロジックは上書きで消される可能性があると思っといたほうがいいくらい．
基本は関連を使ったJPQLでのアクセスとなるため，JOINは使うことはない．NEWキーワードによるコンストラクタへのパラメータ渡しはテーブルの項目のみならずEntityそのものを渡すことができるからだ．
ネイティブクエリはたしかにJPQLでは扱いにくいが，EntityとNEWキーワードによるDTOでほぼ事足りる．業務アプリでそれで足りない場合というのは正直考えにくい．
そもそもネイティブなSQLを発行したい場合
@Resource private DataSource ds;
という2行をかくだけでDBUtillなど好きなライブラリを使える．JPAを使う場合は
@PersistenceContext private EntityManager em;
という2行を書いているのだから別にそんなに変わらない．どうしてもJPAと同時に一元管理したいのならばEntityManagerとDataSourceを一元管理できるライブラリを1枚かませればいいだけ．どうせトランザクションはJTAによって管理されるし困ることはないはず．
1年半くらいJPAを実務で使い続けてきているけど，困ったことはないですわ．最初のころに書いたコードは確かにネイティブクエリとかいろいろとやろうとしていたコードが確かに残ってますが，これは笑うところです．
DB管理者がテーブルの関連等をちゃんとやってくれないからJPAで扱いにくいというのならそれは避難していいところだと思います．
