今回Java EE6開発にあたってDB周辺はJPA(実体はEclipseLink)を利用しています。
ORマッパーは賛否ありますが、(個人的には)慣れるとやっぱり便利だよなー、と(^^;
もちろん性能などは要注意ですが。
(なので性能面に関しては前に書いたエントリ「JPQLを利用する際に行っていること」の手順で確認して使ってます)
Java EE6の場合だと、何でもかんでもEntityベースの操作、というわけでもなく、JPQLを通じてクエリも書けるので、場面にあわせて柔軟な対応ができるのではないかと思います。(最悪Native Queryもあるし)
しかしながら、ORマッパーを利用していると、どうしても避けられない作業として
「DBのスキーマ変更」
に伴うEntityの修正があって、手間に思うこともしばしば。
対応方法はスキーマ変更の影響範囲や大きさ等の状況によって異なると思うのですが、自分は主に以下の手順で行っています。
あ、その前にEntityクラス新規作成時の流れから書かねば。
新規にEntityクラスを作る流れ
NetBeansだとプロジェクトを右クリックして「新規」->「その他」で以下画面から「持続性」->「データベースからのエンティティ・クラス」です。
先日参加した「WebLogic Server勉強会」の「Java Persistence API入門」ではEclipseでも同じことをデモで紹介（ネットワーク環境からかデモが上手く動かなかったですが…）されていたので、同じ形かと思います。
ほぼこれだけです(^^;
当初は生成されたEntityのクラス名をリファクタリングで変えたり、とか色々していましたが、そうするとスキーマ変更時に手間が増えたりもするので、最近ではなるべく自動生成された素の状態を利用しています。
ただ全部が全部、素で使えるわけでもないので、手動の修正も行っています。
DBのスキーマ変更でEntityクラスを変えるとき
やり方は色々あるかと思います。自分が実際に利用する方法としては
- 既存のEntityクラスをそのまま手で修正
- 既存のEntityクラスを削除して、IDEの自動生成機能でEntityクラスを再生成
- 新しく空のプロジェクトを作ってIDEの自動生成機能でEntityクラスを生成し、WinMergeで既存プロジェクトのEntityと比較しながら既存を修正
の３つです。
軽微な変更は上２つで大体対応可能ですが、少し影響範囲の大きい場合は（ミス防止のため）３つ目の方法でやっています。
既存プロジェクトと、Entity自動生成用の別プロジェクトのフォルダを比較して
Entityクラスごとにチェックしながら既存Entityクラスへ反映
手で修正されているEntityなどが混じっている場合には特に有効です。
間違えてEntity丸ごと消してしまうとえらいことなるので(^^;
その他、可能な修正としては
（方法はJPAでEntityからテーブルスキーマを生成する方法を教えて頂きました！」参照）
等もありますが、実際にはあまり使っていません(^^;
いずれにせよ、テーブル数が多くなってくると中々手間だったりして、何か上手い方法ないのかな、とも思ったり。まだあまり積極的に方法を調べていないので、こんな方法もありますよー、みたいな情報あったら教えて頂けると嬉しいです。
