当たり前が出来てないと大変なのも当たり前
JPAに限らずフレームワークやライブラリといった環境にあわせた開発をするのは当たり前なんじゃないの？
よくJavaなのにVBやCOBOLやCみたいな思想で書かれてるとかを非難するのと同じように．View層だってStrutsの考え方でJSFを扱ったら大変なことになると思うし，JSFの考え方でStrutsを触っても大変なことになると思う．
JPAならばRDBというもっとも基本となるところに強く影響するため，View層の思想よりうける影響はでかい．JPAは数あるO/Rマッパの中でも非常にシンプルなものだと思う．DBに関連をつけておいて，Entityクラスはすべて自動生成．
http://d.hatena.ne.jp/shin/20080618/p2
もしくはEntityクラスからDBを自動生成．テーブルのカラム情報はそのままプロパティになる．
ライブラリはおいておいて、もちろんフレームワークを使えばそれに適した設計を行うのが当たり前。
でもそれが出来ていないと大変ですよ、ということが言いたいことです。
あと、フレームワークって最終的には開発プロセスと切っても切れない部分があるんじゃないかなあと最近良く思います。
一番勝手しったる感じのJSFというかWebフレームワークでも、Actionベースなのかイベントドリブンな感じなのか
ステートレスなのかステートフルなのか、Viewに対する考え方と様々な思想があるのでその中から適したものを選ぶ必要はあるでしょう。
ここからはDaoに関しての個人的な意見。
Dao部分に関しては自分が関わる開発では出来るだけ次のような手順を踏みたいなあと自分は考えています。
- 設計書からSQLを書いてみて（または既存資産を流用して）、実際にどのような結果が返ればいいかをSQLを発行して確認する。
- そのSQLが正しいかをコードレビューして、大丈夫そうならばそのSQLをベースにしてDao部分開発(S2Daoならここで2waySQL化)
- フレームワークはなんでもいいですが、Dao部分の開発
- UT（ローカルDBなどでテスト）
- IT(実際のOracleなどのDBでテスト)
この手順をなるべくサポートしてくれるフレームワークがいいなあと思っています。
JPAとかだと実際に動かさなくてはいけないのが敷居が高いかなあと。あとはJPQLも正しいかどうか事前にレビューしにくい。
わかってしまえば早いのかもしれないですが。
それとツールサポートがどれだけできるのかがポイントですねえ。今のところそこまで有力な情報ないのですが（JBoss Toolsとかくらい？）、
あったとしてもEntityがないとJPQLが正しいかどうかをテストできないんじゃないかなあと思ったりしてます。
で、結局最後はSQLに変換されるならSQL書けばいいじゃんというのが自分の考えです。
まあ安直っちゃあ安直ですが、悩むパワーはそのほかのことに使いたいし案件終わらせることが最優先なのでｗ
SQL脳とJava脳のコンテキストスイッチみたいなものが明確に手順で分かれてて少ないっていう意味もあります。
上記の手順だと1をやる人と、3で実際コード書く人で分業したりしてたので、それで確度高くできるかなあと思ってます。
SQLを見れば後からもわかりやすい。そこに動くそのもののSQLがあるので。
あとは案件的な制約でDB設計が毎度毎度いじれるのかって話もあります。みんないじれてんのかなあ。
JPAもRailsのActive Recordもそうだったりしますが、DB設計がある程度それ用にいじれる場合はいいんですけど、
日本の開発で特に移行とか追加案件のような新規以外の案件やってきた身としては
DB設計がいじれない事がほとんどだったのでその辺気になります。無理やり使う系なんかなあ。
というわけで上のような手順を踏もうとすると、なんだかんだでS2Daoがやっぱり一番使いやすいなあというのは、
S2Daoファンの私としては思うのでした。
この辺は、基本的にうくくな人と同じ思いですね。この工員AとBの話、普通にあるからねえ。。。。
