フレームワーク開発にORMは必要!? ORMの問題点と付き合い方とは!?

ORMは多くのフレームワークに標準搭載されていますが、ORMの利用って世間では当たり前なんでしょうか、それとも思わぬ落とし穴にハマる可能性が高いので、百害あって一利無しなのか。

Symfony2開発に携わっていた頃、現場のエンジニアがDoctrineの技術調査をしてみると、パフォーマンスがいまいち(確かやたらメモリを食うとか…環境や設定に問題もあったかもしれませんが)だったので、現場判断で素のSQLによる実装対応が決定。

それからCakePHP3開発に携わった際、Cakeのクエリビルダーを利用するか悩んでいると「あまりフレームワークに依存した実装にはしたくない」とのCTO判断により、結局色んなフレームワークに触れるも、ほぼ一度もORMで実装した経験がありませんでした。

なのでORMの有用性、どれだけ現場の開発にプラスに働くのか、あまり知見がないのですが、世間では結構な方がORMの害悪っぷりを言われていますね(;^_^

O/Rマッピングは百害あって一利なし!

ORMは無用の長物

ORMがアンチパターンである11の理由

そんなに使い道のない機能であれば、世の中から淘汰される訳ですが、多くのフレームワークに搭載されているので、上手く利用さえすれば皆が幸せになる…かも(学習コストは高さそうだけど)

魔法の代償

ORMはあまりSQLを知らずとも、簡単なCRUD処理は書けるため、ある種の魔法のようなツールに思えますが、適切な使い方をしていなければ思わぬ問題にハマることも。

POINT仕様を理解してないと、効率の悪いSQL(N+1問題)が生成される可能性有.

ORM利用では生成されるSQLが意図した命令になっているか確認がマストになります。

以下のエントリーはORMだけでなく、SQL全般のパフォーマンスに言及されたり、ORMを使う場合に考えられる問題と対策を以下のスライドが丁寧にまとめられています。

なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策

O/Rマッパーによるトラブルを未然に防ぐ

他のメリットして、DB間の方言をラッピング、簡潔な記述が可能、SQLインジェクション対策など。

移行の手間

最近Rubyでの少人数開発から、一定期間後にGoへ移管する話をよく聞きます。

理由はメンテナンス性やパフォーマンス、バージョン互換性など色んな理由があるとか。

TaNA
Rubyに限った話ではなく、今後も技術の進化により、システム自体のライフサイクルもより早くなり、システムもエンジニアも、モダンな技術への対応に迫られるんじゃないかなぁ〜と個人的には感じております。

そう考えた時、ちょっと矛盾する考えなんですが、フレームワークの便利さに依存し過ぎるのも…

ORMは一見してどんなSQLが発行されるのか分からないので、仕様の全容を理解した人が減り、レガシー化した場合などは、実際に動かして都度SQLの確認が必要になり、リプレイス・移行時は仕様理解に手間が増えそうかなぁ〜とも思えます。

言語・フレームワーク毎にORMを覚える学習コスト、将来あるかもしれない移行の手間、一見してSQLの仕様が掴めないコード(ORMでもメソッド名で意図は伝えられるけど)などを考えると、今後も積極的にORMに関わる事は無いかなぁと。

共存という道

また良いプロダクトを作るために「共存させる考え方」もあるので、双方のメリット・デメリットを理解し、二元論で考えない適材適所の利用に関するスライドを見つけたので紹介しておきます。

ORMとの付き合い方

確かにORMの利点の一つであるテストの容易さは魅力的だし、Qiita上でのコメントを見ていると、結構SQLを書けないエンジニアは多かったり、あとはセキュリティー(SQLインジェクション)や開発速度の観点から導入する現場はある模様です。

現場のスキルレベルや期間・工数を考えるマネージメント目線では、別の選択肢も増えそう。

私はSQLかORMかで統一されていないと気持ち悪いですが、あまり二元論で考えても、ちょっとイデオロギー的な思想になりそうなので、まあ上手いことやれるなら、混在もありかなと感じます。