（旧版）ORMは百害あって一利なし

Qiita記事に同じタイトルで文章を投稿することにしたので、（検索エンジン経由でくる方はいないと思いますが）こちらの記事は（旧版）とさせて頂くことにしました。2018/11/13

リレーショナルデータベース（ＲＤＢ）とのマッピング技術と言えばよいのだろうか。ていうか細かい定義はしらない。ＯＲＭという考え方がある。たしかにすべてのデータベースのデータとデータの性質とデータの機能（メソッド）が定義できれば構造データとして扱えるのかもしれない。

ところが、ＳＱＬを柔軟に扱って思い通りのデータをとることと、いったい何が違うのだろうか？という問いが頭をもたげている。ＷＥＢアプリケーションのＯＲＭを考えた場合だいたいＯＲＭは不要であるというのが持論て言うか害悪でしかない。

どっちみちＯＲＭの外側か内側か（そもそも内と外という考え方はどうでもいいかもしれないが）わからぬがＳＱＬでＲＤＢがあるのである。メソッドを設ける前にＳＱＬでごにょごにょすれば、だいたいこと足りないか？

そういうわけでＳＱＬをうまく使ってデータとアクセスするモデルをＯＲＭと言うなら分かるが無駄にごてごてしいマッピングクラスを見ていて私が出した結論はＯＲＭって百害あって一利なしってこと。

もしかしたら項目追加を自動化したらＳＱＬ直書きよりも素直にデータを扱えるかもしれないけれど、だいたい工数が増える気がする。

それならば、ＳＱＬでＭＶＣ的に書けるとかグル―言語なしでＷＥＢアプリがつくれるとか、ＳＱＬ主体でＷＥＢアプリをつくるほうがずっといいと思う。ＳＱＬ言語の柔軟性を奪ってＳＱＬを蔑ろにしたような開発ってなんか意味あんの。なんにもない気がする。

ミドルウェア-ＲＤＢの場合はＳＱＬをいかにうまく扱うかが品質が高いアプリケーションをつくるコツである…という確信を、いい意味で裏切ってくれるＯＲＭはまだこの世にないと思っている。DDD(ドメイン駆動開発)やSOA（サービス志向アーキテクチャ）における課題解決方法みたいに語られることもあるが、果たしてそうなのだろうか？

そして、そういうＯＲＭなのか代替案なのかわからぬが、SQL-ORMが他にとって変わる何らかの技術が選ばれて業界標準化されるパラダイムシフトが起こるにはまだもう少しかかると思っている。