ORM が引き受けている責務を分解してみる | ashunar0

はじめに 最近 Twitter では、ORM 不要論や生 SQL 回帰論が話題に上がっています。「ORM は要らない」「生 SQL でいい」「いやクエリビルダくらいは欲しい」といった意見が見受けられますが、自分には正直よくわかりませんでした。 というのも、僕は「SQLを書くの面倒」「軽量」「なんとなく読みやすい」というあまりにも短絡的な理由で、Drizzleしか使っていないからです！！ とはいえ、こうも話題に上がっている以上、何も学ばずにスルーするというのもいささかもったいない気がしたので、ORM が実際に何を引き受けているのかを分解してみることにしました。この論争の解像度が少しでも上がればいいなと思いながら調べています。 「ORM」が指すものの幅 分解の前に、用語の話をします。 ORM は Object-Relational Mapping の略で、名前の通りならオブジェクトとリレーショ

[Magicant]

行とオブジェクトの変換だけやってりゃいいのに余計な機能がてんこ盛りの ORM が多過ぎる

[takafumiat]

AI時代ならSQL直書きでいいでしょ。ORMなんて、SQLをオブジェクト指向ライクに構築しようとした過去の遺物じゃない。余計な処理が多いしクエリチューニングもしずらい。

[devrabi]

クエリビルダー、エンジン、マッパー、ものによってはトラッキング。エンジン、マッパーがあれば十分で、表現力の足りないビルダーを使おうとするあたりからおかしくなりますよね

[prograti]

JPAのUnit of Workパターンを採用したORMとかは使いこなせるとかなり便利だけど、ぴったりハマるかどうかはプロジェクト次第なので、プロジェクトの特性に合わせて選択する感じかな

[nakag0711]

SQLより表現力が劣るのにORM側が主導権取ろうとするとおかしくなる。あとefgあたりはオブジェクト関係ないからORMとも関係なさそうだけど、これらをORM一般が必要であることの根拠にすることってあるんだろうか