ORMは今でもアンチパターンなのか？

• ORM（オブジェクト関係マッパー）は、ソフトウェア開発においてアンチパターンとして批判されることが多い。
• しかし、この批判は誇張されており、ORMは他のソフトウェアツールと同様に、本質的に悪いものではない。
• ORMの実際の問題は、しばしば誤用されたり誤解されたりすることにある。
• ORMとリレーショナルデータベースは異なるパラダイムで動作するため、データモデリングやリレーションにおいて難しい問題が生じることがある。
• ORMは単一責任の原則（SRP）と関心の分離（SOC）の原則に違反しているが、こうした批判は決定的な問題ではない。
• ORMの本当の問題は、効率性と可視性にある。
• 適切に使われなければORMは非効率になりうるが、クエリを最適化し、性能を向上させるための機能を備えている。
• ORMがデータベースと何度も往復するN+1問題は、データローダーを使うことで緩和できる。
• ORMの最大の問題は可視性とデバッグである。明確なエラーメッセージを提供しなかったり、問題の理解や解決を難しくしたりすることがある。
• ORMは正しく使えば生のSQLと同じくらい効率的になりうるが、開発者はその機能とネイティブSQL相当の手段を活用する必要がある。
• 複雑なクエリや問題のあるクエリでは、生のSQLクエリに切り替える必要がある場合もある。
• 全体として、ORMは本質的に悪いものではないが、潜在的な問題を避けるためには慎重で十分な知識を伴う利用が必要である。

[GN⁺]

Hacker Newsの意見

• ORMの限界と欠点、たとえば別のデータベースを使えないことやSQLの知識が必要であることなどが批判されている。
• 文字列補間と生のJDBCに近い方法で、データレイヤーをクエリ単位で構築するほうが、より良いアプローチだと見なされている。
• ORMはしばしば基本的なテーブルおよびビューのマッピングにしか対応せず、SQLの高度な機能や能力を無視する。
• ORMには2つのタイプがある。ドメインモデルを基盤にするものと、既存のデータベースからドメインモデルを生成するものだ。
• jOOQやHibernateのように実装や機能が異なるORMは、それぞれ別の目的で使われる。
• ORMは、多数のテーブルと適切な外部キー関係を持つ複雑なアプリケーションで有用になりうる。
• 文字列リテラル内で生のSQLを使うことはORMの代替と見なされており、クエリラッパーを生成するツールを使うこともできる。
• すべてをひとまとめに隠そうとせず、独自のクエリ言語を導入しない実用的なORMが好まれる。
• SQLAlchemyは、SQLを再発明せずに便利なクエリレイヤーを提供するアプローチとして高く評価されている。
• ORMを使わない場合、開発者は独自のデータベースインターフェースを作成して保守しなければならず、その結果としてバグやセキュリティ脆弱性が生じる可能性がある。
• ORMがSOLID原則に反するという批判は、学術的な教えと実際の開発との衝突だと見なされている。
• 経験不足や学術的な慣行の影響によって問題が発生し、予算超過につながることがある。