結論だけ先に言うと止めた方が良いです。
ORM自体アンチパターン？
ask.fmで頂いたのですが、以下の様な記事が話題になっているようです。
ORMがアンチパターンである11の理由
中身を読むとああー思うところがあるのですが、こちらの内容を踏まえた上で、私の意見を述べたいと思います。
元にするORMはJPAですが、他の一般的なORMでも似たようなことが言えるはずです。
ORMができること
ORM自体はRDBとオブジェクト指向言語のミスマッチをどうにかして一つのレイヤーだけで解消しようとするために生まれたものです。
DAOパターンでRDBとオブジェクトのマッピングを書いた事がある人はわかると思いますが、RDBからオブジェクトへの変換、もしくはその逆はマッピングするだけでも非常に多くのコードを必要とし、また、場合によって複数のオブジェクト/RDBのマッピングの順番を併せることが必要だったりと非常に面倒くさいです。
そういった面倒くさいことを簡単に行ってくれるのがORMです。
ORMを使ってもSQLで行っていた難しいことを簡単にするといったことは出来ません。
あくまで、面倒くさい事を面倒くさくなくするだけです。
ORMの制限
ORMの制限について考えてみます。
これは単純に言えば、SQLほど柔軟性がないということです。
大体のORMは複数のDBに対応するため、本来のRDBMSが備えている機能のサブセットしか使うことが出来ません。
それにより、SQLを直接書くよりも表現力は格段に下がります。
何がSQLにできて、何がORMにできなくなったのか
SQLでは複雑なJoinや、本来関連がないはずのものに強制的に関連付けを持たせること等が出来ました。
そういったことはORMではしにくい、もしくは出来ないです。
SQLであれば、DB設計が破綻していたとしても、それをどうにかして繋ぎ止めることが出来ました。
ORMでは表現力の貧弱さからDB設計が破綻した場合に、まともに動作することが出来ません。
ORMがきちんと機能する時
きちんとした正規化ができていること*1が大前提です。
そのうえで、ORMの表現力の低さを補うために、ORM用のスペシャルなチューニング*2を行う必要があります。
結局ORMの貧弱さを設計で補う必要があります。
一言で言えば、設計がきちんと出来ていないとORMは満足に機能しません。
先の記事にも書いてあるとおり、オブジェクトではRDBのマッピングを効率よく表現はできません。
それはRDBは学問に基づいて思考され、オブジェクト指向は経験により思考されたものなので、そもそも理論体系が違うからです。*3
ORMを使うためには
まずは、設計をしましょう。
どれだけ設計をしてもしょせんは机上の空論ですから、破綻することはよくあります。
その場合には実装の内容を設計に反映させましょう。
SQLでは設計が破綻してもSQLの柔軟性によりどうにかできていたものが、ORMではどうにもできません。
ORMの最大の利点
ORMの最大の利点はRDBの変更をオブジェクト側に反映させやすいことです。
JDBC接続の場合、INSERT文、UPDATE文、DELETE文をそれぞれ修正しなければいけませんが、ORMでは一箇所修正するだけで事が足ります。*4
ウォーターフォールへのORMの適用
ウォーターフォールを採用した実案件では設計から実装への一方通行になっている場合があります。
実装時にデータモデルの破綻が判明した場合も、いろいろな理由*5により設計に反映が出来ない場合があります。
その場合、ORMを適用した場合の最大の利点を消していることになります。
ここらへんが大規模開発になるとORMが破綻すると言われる原因になっているのではないでしょうか。
ORMを適用した場合の最大の利点かつ、ORMを使用するための大前提が政治的理由によりできなくなっているのですから。
結論
ウォーターフォール案件でのORMは相性が悪いです。
どうしても使いたいなら実装から設計へ反映できるフローを用意するべきです。
