(旧版)ORMは百害あって一利なし

徒然草2.0

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

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

ところが、SQLを柔軟に扱って思い通りのデータをとることと、いったい何が違うのだろうか?という問いが頭をもたげている。WEBアプリケーションのORMを考えた場合だいたいORMは不要であるというのが持論て言うか害悪でしかない。

どっちみちORMの外側か内側か(そもそも内と外という考え方はどうでもいいかもしれないが)わからぬがSQLでRDBがあるのである。メソッドを設ける前にSQLでごにょごにょすれば、だいたいこと足りないか?

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

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

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

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

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

徒然草2.0
スポンサーリンク
シェアする
gomiryoをフォローする
ごみぶろぐ

コメント

タイトルとURLをコピーしました