Hibernateに代表されるORマッピングフレームワーク。
エンタープライズシステムでは適用しづらいじゃないかってよく思う。
きっと、いろんな人がすでに考えてるんじゃないかって思うけど。
ORマッピングフレームワークを使うためには、テーブル設計に対してそのフレームワークのルールを適用しないといけない。
つまり、「フレームワークにテーブル設計を合わす」必要がある。
これが（日本の？）エンタープライズシステムでは難しい。
テーブル設計チームが独立したチームである
アーキテクチャチームとテーブル設計チームが別チームであるため、アーキテクチャチームがORマッピングフレームワークを採用しても、テーブル設計チームにそのルールを適用してもらいづらい。
特に、テーブル設計チームはその会社の旧来の設計手法に則るから、サロゲートキーの採用とかしてもらいにくい。
ともすれば主キーのないテーブルを作ってきたり外部キーは使わなかったり、とてもORMは入れれない。
リプレースのプロジェクトが多い
リプレースの場合、テーブル構造は現行システムのままで、ってことが多い感じ。
今までこれで動いてたから変える必要がないって言われたり。
あとは納期の関係でテーブル設計に工数はかけられないみたいな。
ルールを適用していないテーブル構造でORMを採用すると、ほぼ火を噴く（と思う）。
ORMではなくJDBCを使う
やっぱりSQL文を書くことだと。
エンタープライズだと帳票作成のためにややこしいSQL文を書く必要もあるし。
さすがにJDBCだけというのは工数やバグの確率を考えると現実的でないので、フレームワークは使う。
Spring JDBC抽象フレームワークとか、iBatisとか、DBUtilsとか。
個人的にはS2Daoが最高だと思う。
特に、SQL文をStringで結合なんて読みづらいしやってられないから、SQL文は外部ファイルに書きたい。
デフォルトでそういう機能があるのはiBatisとS2Dao。
S2DaoはSeasar2を使うなら必須。いずれはKuinaに移っていくんだろうけど、基本は同じ。
