ORMについてのとりあえずの所見

元ネタっていうか刺激元は此方。

[db] 「O/Rマッパーがなぜ悪いか？」がなぜ頭悪いか？
kwatch.houkagoteatime.net/blog/2014/12/27/nabokov7/

些か検証仕切れていない部分はあるんだけど。
現時点において
・本質的な部分
・現在(っつか正確にはちょい前)の実装的な部分
のどちらでも、気になる部分が少なからずあるので、端的に書くとおいちゃんは「好まない」感じ。

・現在(っつか正確にはちょい前)の実装的な部分
が単純なんで先に書いておくと「いらんSQL流しすぎで重すぎで結果DBに負荷かけ過ぎ」なのでお好まん。
ただ、これは「改良されつつある」話も耳にするし、きっと「改良されていくだろう」と思うので、現時点ですでに枝葉末節な気もする。

・本質的な部分
で一個、物凄く大嫌いなのが「ORMを使えばSQLを知らなくてもイイ」って論調でなんて言うか「滅びろ」。
「理解した上で、今この瞬間は一端未考慮のブラックボックスでもイイ」はアリだけど「知らなくてもイイ」とかなんていうか「ディスインテグレート（分解消去）」の禁呪唱えてやるから滅びろ。

で、考察に値するのがそれ以降。
「ある一定のほにゃららを部品化して使い回せる」部分は、時々欲しいなぁと思う瞬間はあるんだけど。
ただ実際問題としては「その辺をメソッド化」して切り出せば割と十分にいけるので「無いと困る！ 必須！」ってほど強いモチベには繋がらない。

逆側の否定として「SQLのガリッガリのチューニング」は、それはそれでお好まないので「SQLならチューニングしまくったものが渡せる！ だからORMは駄目！！」ってのは、それはそれでおいちゃんの心をつかまない。
…多分おいちゃんが「Webアプリが多いから」ってのに起因。
業務系だと「ややこいSQLをガリゴリっと」ってのに一定の利があると思うし。
一方で、Webアプリにおいてはどちらかというと「シンプルなSQLを高速大量にぶん回す」事のほうが多いし、そっちを「軽快に」動かす方がメリットあると思うので。

また「インピーダンスミスマッチ」の問題も気になるところ。
とりあえず「生SQL書いている時」に、やっぱり「OOPとは違う脳みそ使ってる」なぁ、とは思うので、その辺はあると思う。
それを「どれくらい美味くマッチングさせられるのか」「やっぱり難しいのか」ってのは、まだ考察仕切れていない…けど、やっぱり「ちょっとOOPとは違うよね」って思う瞬間はあるし、それを「じゃぁOOPにすり寄っていただきましょう」って方向の流れは、どちらかというと違和感がある感じかな。
「最終的なデータの塊」自体は、OOPと集合論とで(ある程度かもしらんが)マッチさせられると思ってるので(っていうかそこで困ったことは無いので)。
・SQLでデータの塊作って
・それをインスタンス(の配列)にして
くらいでいいかなぁ？ って思う事が、正直、多い。

そうすると…

「シンプルなSQL」を回すぶんには、どっちも大差なくて、ってことはつまり「ORMなら部品化出来るよ！」言われても、そも、部品化が必要なほどの状況もほぼなくて。
「ややこいSQL」を使う場合、やっぱり「チューニングしたいよねぇ」って話もあって、それは「将来のORMなら」潤沢に出来るかもしれないけど、現状出来ている訳ではなくて、ってことはここについては「ガリッゴリのSQLを生で書ける」ほうが、どちらかというと現実的で。
あとぶっちゃけ「ORMによって色々書き方とかお作法とか違う」ので、覚えるのめんどい。
SQLは良書あるんだけどねぇ。
ORMにそーゆー良書あるのかしらん？ あったら読んでみたいんだが。

プログラマのためのSQL 第4版

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

この辺を考えると。
「全てのORMを生まれる前に消し去りたい。すべての宇宙、過去と未来の全てのORMを、この手で」ってほど滅びろ、とは全く思わんのですが。
「現時点のORM」は、覚えるコストとかバックのチューニングとか諸々考えた時に、おいちゃん的には「現時点においてはお好まんなぁ」、って判断にとりあえずなるわけです。

ただ一方で「お好まん状況が一式払拭される未来の可能性」が常に頭によぎるので、定期的に何となく「どうだろう？」って覗いている感じ(笑

というわけで、現状の「覗いている結果」を、備忘録のようにメモり。