読者です 読者をやめる 読者になる 読者になる

Fight the Future

何かを始めたら、半分成功したのと同じ

ORマッピングはエンタープライズシステムでは適用しづらい

ORM

Hibernateに代表されるORマッピングフレームワーク
エンタープライズシステムでは適用しづらいじゃないかってよく思う。
きっと、いろんな人がすでに考えてるんじゃないかって思うけど。


ORマッピングフレームワークを使うためには、テーブル設計に対してそのフレームワークのルールを適用しないといけない。
つまり、「フレームワークにテーブル設計を合わす」必要がある。
これが(日本の?)エンタープライズシステムでは難しい。

テーブル設計チームが独立したチームである

アーキテクチャチームとテーブル設計チームが別チームであるため、アーキテクチャチームがORマッピングフレームワークを採用しても、テーブル設計チームにそのルールを適用してもらいづらい。
特に、テーブル設計チームはその会社の旧来の設計手法に則るから、サロゲートキーの採用とかしてもらいにくい。
ともすれば主キーのないテーブルを作ってきたり外部キーは使わなかったり、とてもORMは入れれない。

リプレースのプロジェクトが多い

リプレースの場合、テーブル構造は現行システムのままで、ってことが多い感じ。
今までこれで動いてたから変える必要がないって言われたり。
あとは納期の関係でテーブル設計に工数はかけられないみたいな。


ルールを適用していないテーブル構造でORMを採用すると、ほぼ火を噴く(と思う)。

ORMではなくJDBCを使う

やっぱりSQL文を書くことだと。
エンタープライズだと帳票作成のためにややこしいSQL文を書く必要もあるし。
さすがにJDBCだけというのは工数やバグの確率を考えると現実的でないので、フレームワークは使う。
Spring JDBC抽象フレームワークとか、iBatisとか、DBUtilsとか。
個人的にはS2Daoが最高だと思う。
特に、SQL文をStringで結合なんて読みづらいしやってられないから、SQL文は外部ファイルに書きたい。
デフォルトでそういう機能があるのはiBatisS2Dao
S2DaoSeasar2を使うなら必須。いずれはKuinaに移っていくんだろうけど、基本は同じ。

Object Query Mapping

iBatis in Action』に載ってた。iBatisはObject Relational Mappingじゃない。iBatisはObject Query Mappingだと。
なるほど、と思った。
何でもORマッピングと思ってました。勉強不足でした。
ORマッピングはメタデータでのマッピングがあると。
Hibernateでいうとクラスとテーブル、フィールドとカラムの対応付け。
XMLでもアノテーションでもいいんだけど。
でもiBatisは実行するSQL文とオブジェクトのマッピングだと。
テーブル構造がどうなっていようが関係ないわけです。