ORMツールを使用する必要があるのはいつですか？
私はTDD、A/Bテスト、Doctrine、デザインパターンなどではなく、ほとんどの場合Webサイトの作成がWordpress、FTP、Joomla、および手続き型コードと同義であるWeb開発の一部で育ちました。この領域をあまり移動していなかったので、サイトの作成と管理にオブジェクトリレーショナルマッピングとORMツールが必要になる時期を知りたいと思います。いつ使用すべきかの一般的な（しかし実際の例）を提供できますか？
必要？決して。
ORMは、データベースの抽象化レイヤーです。それらは、オブジェクトグラフとデータベーステーブル/関係の間のトランスレータとして意図されています。この機能により、単純なデータアクセスが簡素化され、大きなオブジェクトモデル/データベースを使用すると、データアクセス用のボイラープレートコードの記述（IDによるレコードの取得、IDによる削除、レコードの更新と挿入）に費やす時間を大幅に節約できます。
有用？ほとんどの場合、上記のポイントについて。
したがって、ルールはありませんが、ORMは基本的なDB操作（挿入、更新、削除、選択）に最適です。より複雑なものが必要な場合は、プラットフォームの標準APIを使用するのが最適です。
ORMツールはCRUD、に使用する必要があります。コードの80％は何度も何度も書くのが面倒なので、壁に頭をぶつけたい。
残りの20％には、ストアドプロシージャのような「古い学校」の方法（パフォーマンスの最適化を必要とする操作など）を自由に使用してください。
ORMを効果的に使用して、データベースデータのCRUDスタイルを取得および更新するための組織化された効果的なリポジトリクラスを作成する簡単な例については、以下を参照してください。
ORMは2つの価値のある目標を提供します。
データベース固有の方言の詳細の一部を抽象化します。 SQLが奇妙なことから開発者を隔離する。
ほとんどのORMは80〜20種類のツールであり、SQLを直接使用する場合と比較して、永続化の作業の約80％を大幅に簡略化できます。単純なアプリケーションの場合、プラットフォームは設計の決定を指示できることが多いため、80％は実際には100％です。
より大きく、より複雑なアプリケーションでは、どのツールでも予期できなかった問題が常に発生します。これが発生すると、良いORMと悪いORMの違いがはっきりとわかります。
優れたORMは、データを取得するためにカスタムSQLを発行する必要がある場合、または必要な用途に成長するための単純な拡張機能またはイントロスペクションメカニズムを提供する必要がある場合に、開発者の邪魔にならないでしょう。貧しい人々はこの種のものの邪魔をするだけです。開発者がこれらのカスタムジョブを下位層で実行する必要があります。
ビジネスインテリジェンスまたはその他の便利な動作を永続エンティティにアタッチします。
ORMのクラスマッピング機能を最大限に活用するには、多くの場合、ORMの開発者がアプリケーションオブジェクトの役割を深く理解する必要があります。モデルオブジェクトは、それらがラップする永続状態とは非常に異なる役割を果たします。
具体的には、データベースの行と列は真と思われる一連の事実を表していますが、モデルのメソッドと継承グラフは、アプリケーションが操作するルールと式です。
ORMが2つのアイデアを統合すると、それらは多くの慣用的な方法で開発者を妨害します。テーブルの一部ではないリレーションを操作する方法はありません（明らかな反例は、結合またはgroup by句を含むselectによって返される行です）。別の内訳は、すべてのテーブルに主キーが必要であると想定していることです。または、主キーは整数または単一の列でなければなりません。 ORMがこれをめちゃくちゃにすることができるもっと微妙な方法は、多対多のプロパティなどのオブジェクト機能を提供することです。これは、データベース接続が適切に機能するように要求するです（エンティティの関係は永続性に関連します）。
アプリケーションがリレーショナルデータベースを使用している場合、コードには多くのSQL（または.NETを使用している場合はLINQ）が含まれます。
アイデアは、データアクセス層とビジネスオブジェクトをコーディングなしですばやく作成することにより、アプリケーションコードとデータベース間の相互作用を簡素化し、開発者が特別なビジネスルール（存在する場合）を追加してロジックを拡張できるようにすることです。
オブジェクトリレーショナルマッピングツールは多数あります。すべてのツールが同じというわけではありません。単純なものもあれば、フレームワーク全体になるほど複雑なものもあります。
彼らはすでに構築されたデータベース（テーブル）に依存し、データベースからテーブル定義を読み取ります。
0-オブジェクト（通常は1から1）を表すクラスを作成します。このようなクラスには、データベースからのデータの読み取り、書き込み、更新、削除を行うメソッドが含まれています。一部はLINQ（.Net）をサポートし、一部は独自のオブジェクトクエリ言語を持っています。
主キーの生成とテーブル間の関係を自動的に処理する
2-1回のメソッド呼び出しで、テーブルに関連するデータを自動的に読み取り、返すことができます
3-コーディングなしでデータベースを切り替えることができます
4-データバッファリングに注意してパフォーマンスを向上させる
5-必要なSQLを生成し、データを自動的に取得してデータベースに送信
6-自動的にWebサービスを生成するもの（例：Oxygen）
7-一部は自動的に監査コードを生成できます
8-一部はストアドプロシージャを作成できます
9-認証サポートを提供する
10-いくつかは自動的に多層アーキテクチャをサポートします
11-Some support .NET Entity Framework
したがって、プロジェクトで上記のサービスのいずれかが必要な場合は、ORMが最適です。
.Netユーザーの場合は、ORMとEntity Frameworkのどちらを使用するかを決定する必要があるかもしれません。