行とオブジェクトの変換だけやってりゃいいのに余計な機能がてんこ盛りの ORM が多過ぎる
SQLより表現力が劣るのにORM側が主導権取ろうとするとおかしくなる。あとefgあたりはオブジェクト関係ないからORMとも関係なさそうだけど、これらをORM一般が必要であることの根拠にすることってあるんだろうか
JPAのUnit of Workパターンを採用したORMとかは使いこなせるとかなり便利だけど、ぴったりハマるかどうかはプロジェクト次第なので、プロジェクトの特性に合わせて選択する感じかな
クエリビルダー、エンジン、マッパー、ものによってはトラッキング。エンジン、マッパーがあれば十分で、表現力の足りないビルダーを使おうとするあたりからおかしくなりますよね
AI時代ならSQL直書きでいいでしょ。ORMなんて、SQLをオブジェクト指向ライクに構築しようとした過去の遺物じゃない。余計な処理が多いしクエリチューニングもしずらい。
色々あってSpannerに特化したクエリビルダーを作ってたけど、ここ数日の議論で方針転換して2way SQLライクのORMに舵を切ることにした。
ORM が引き受けている責務を分解してみる | ashunar0
行とオブジェクトの変換だけやってりゃいいのに余計な機能がてんこ盛りの ORM が多過ぎる
SQLより表現力が劣るのにORM側が主導権取ろうとするとおかしくなる。あとefgあたりはオブジェクト関係ないからORMとも関係なさそうだけど、これらをORM一般が必要であることの根拠にすることってあるんだろうか
JPAのUnit of Workパターンを採用したORMとかは使いこなせるとかなり便利だけど、ぴったりハマるかどうかはプロジェクト次第なので、プロジェクトの特性に合わせて選択する感じかな
クエリビルダー、エンジン、マッパー、ものによってはトラッキング。エンジン、マッパーがあれば十分で、表現力の足りないビルダーを使おうとするあたりからおかしくなりますよね
AI時代ならSQL直書きでいいでしょ。ORMなんて、SQLをオブジェクト指向ライクに構築しようとした過去の遺物じゃない。余計な処理が多いしクエリチューニングもしずらい。
色々あってSpannerに特化したクエリビルダーを作ってたけど、ここ数日の議論で方針転換して2way SQLライクのORMに舵を切ることにした。