Fight the Future

Java言語とJVM、そしてJavaエコシステム全般にまつわること

IT勉強会での初プレゼンなどお助けします!

勉強会でスピーカーをやりたいけど、プレゼンが初めて、苦手という方に無償でコーチできます。スライドのレビューや録画したリハへのアドバイスなどなど。Twitter@jyukutyoまでメンションでもDMでもお気軽にご連絡ください。

私はIT講師の経験があり、プレゼンはデブサミやJJUG CCCなど200人規模の経験が豊富で最大800人の前でプレゼンしました。海外ではDevoxxUSで。デブサミ2017では公募スピーカー1位、デブサミ関西2012アワードで5位となりました。

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

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文とオブジェクトのマッピングだと。
テーブル構造がどうなっていようが関係ないわけです。