別にORM完全否定派というわけではないが、データ設計と管理をするにあたって本当にORMが適切な実装時の道具かはよく考えたほうがいい気がしている。
あと自分の触ったことあるORMなんて世の中に数多存在するもののうち0.00000001%くらいだと思うのでかなり偏った意見であるけど将来の自分に向けてのこしておく。あとこんな息巻いてる自分もOSSのORMを使わせてもらってはいるのでORMコントリビュータ各位への敬意はあっても他意は全くない。
データ設計について
Clean Architecture やら DDD やらに当てられたというわけでもないが、補強はされたなという所感ではあるものの Context Map とか Aggregate を意識したドメイン定義した時点でそれ以上の内部表現はいらなくなる。
また、(dieselなど)ORMによってはサロゲートキーを強制したりしていて、正直な話not for meな場面がないわけではない。
そもそもORMに強い依存を強いられる時点で取り回しが悪い。
また、ORMはRDBを前提としているものもあり、そのような場合バックエンドの詳細にまで依存させることがあってこれはテストのしやすさを阻害する一因にならないでもない。
とにかく、ビジネス個別に作られたわけではない汎用ツールたるORMはどれだけ自分らのシステム構成に侵食してくるかよく注意すべきだろう。
それに加えてEntity層にコアドメインとなるエンティティを定義しておけば永続化層のマッピングはどうとでもなるが、RDBだけを想定しているようなORMを使っていた場合にNoSQLにしようとか思う場合結局ORMを捨てる選択が必要になって徒労感が否めない。(実際にこういう検討が行われるかは度外視してる)
データ操作について
ORMについて一番疑問を持つのが直接クエリを書けばいいものを、なぜどんなクエリが組み立てられるかわからないクエリビルダを使ってN+1を回避するための記事がこの世にはびこってるのか不思議でならない。
ORMは適当に使えてしまうので射影をしないような実装をカジュアルにできてしまう問題もある。
要は気にしなくていいことを気にしなくてはいけない手間がいくつか増えるような感覚を覚えるのだ。
ORMがうまいことDBエンジンによって文法の差異を吸収してくるって意見も分からないではないけど、Repositoryパターンを使ってれば問題になることはないので、ORMのクエリビルダがある人にとっては「楽ができる」とか「わかりやすい」というのならばよく相談したほうがいいと思う。
個人的にはビジネス要件に関わりうるDMLをなぜブラックボックスにしていいのか理解に苦しむところではある。
DDL的な使い方について
これはRDBに限った話だけど。
テーブル定義の管理をコードで管理したいというのは理解できるけど結局ORMの乗り換えが実質無理ということなので正直うまみを全く感じない。
sqlxとかみたいなもので生DDLとしてマイグレーション履歴の管理を行うということはそんなに突飛なことではないし、個人的な話ではあるけどテーブル定義は制約含めてRDBMSから直接見たほうが明確。
なんといってもわざわざテーブル定義を書くためだけにORMのドキュメントを適宜参照しなくてはいけない場合がある時点で問題のレイヤーを無駄に増やしているように思えてならない。
ORMの利点について
因果が逆かもしれないけど、多分普通に使われてるから衝突が少なくて済む。
しめ
結局のところ自分はORM否定派だったことがわかったけどすでに動いちゃってんならまあ、デメリット理解したうえでうまく付き合うよってくらいのスタンス。 消極的なこと言っても仕方ないのでORMとうまく付き合う方法とやらを模索するしかない。
