なぜORMを使用する必要があるのですか？
ORMを管理/クライアントに使用する理由の「長所」を動機付けた場合、その理由は何でしょうか。
回答ごとに1つの理由を試してください。これにより、投票されたものが最良の理由として表示されます。
データアクセスをより抽象的でポータブルにします。 ORM実装クラスはベンダー固有のSQLの記述方法を知っているため、その必要はありません。
ORMを使用する最も重要な理由は、リッチでオブジェクト指向のビジネスモデルを保持しながら、それを保存し、リレーショナルデータベースに対して効果的なクエリをすばやく作成できるようにするためです。私の観点からは、優れたORMが、作成できる高度なタイプのクエリ以外の他の生成されたDALと比較した場合に得られる本当の利点はありません。
私が考えているクエリの1つのタイプは、ポリモーフィッククエリです。単純なORMクエリは、データベース内のすべての図形を選択する場合があります。図形のコレクションが返されます。しかし、各インスタンスは、その識別子に従って正方形、円形、または長方形です。
別のタイプのクエリは、単一のデータベース呼び出しでオブジェクトと1つ以上の関連オブジェクトまたはコレクションを積極的にフェッチするクエリです。例えば各シェイプオブジェクトは、頂点コレクションとサイドコレクションが読み込まれた状態で返されます。
ここで他の多くの人たちと意見が合わないのは残念ですが、コード生成自体がORMを使用するのに十分な理由だとは思いません。 ORMのような概念上のオーバーヘッドやパフォーマンスのオーバーヘッドがないコードジェネレーター用の多くの優れたDALテンプレートを作成または検索できます。
または、ORMを使用するために適切なSQLを記述する方法を知る必要がないと思われる場合も、私は同意しません。単一のクエリを作成するという観点からは、ORMに依存する方が簡単なのは事実かもしれません。しかし、ORMを使用すると、開発者がクエリがORMおよび変換後のSQLでどのように機能するかを理解していない場合、パフォーマンスの低いルーチンを作成するのは非常に簡単です。
複数のデータベースに対して機能するデータレイヤーがあると、メリットがあります。それは私が頻繁にそれに頼らなければならなかったものではありません。
最後に、ORMのより高度なクエリ機能を使用していない場合、学習とCPUサイクルを減らして残りの問題を解決する他のオプションがあります。
そうそう、開発者の中にはORMで作業するのが楽しいと思う人もいるので、開発者を幸せに保つという観点からもORMは優れています。 =）
開発のスピードアップ。たとえば、クエリ結果フィールドをオブジェクトメンバーにマッピングしたり、その逆を行ったりするなどの反復コードを排除します。
サポートするOOデータアクセス層でのビジネスルールのカプセル化。不格好なトリガーおよびストアドプロシージャ言語の代わりに、好みのアプリケーション言語でビジネスルールを記述（およびデバッグ）できます。
基本的なCRUD操作のボイラープレートコードを生成します。一部のORMフレームワークは、データベースメタデータを直接検査したり、メタデータマッピングファイルを読み込んだり、宣言クラスプロパティを使用したりできます。
抽象化されているため、別のデータベースソフトウェアに簡単に移行できます。
開発の幸福、IMO。 ORMは、SQLで行う必要のあるベアメタル処理の多くを抽象化します。コードベースをシンプルに保ちます。管理するソースファイルが少なくなり、スキーマの変更に数時間の維持が必要ありません。
現在、ORMを使用していますが、これにより開発が加速しました。
オブジェクトモデルと永続性モデルが一致するように。
単純なSQLクエリの重複を最小限に抑えるため。
VS2005のDALツール（スキーママッピング、TableAdapters）から生成されたコードを回避するためです。
私が1年以上前に作成したDAL/BLLは、他の誰かがそれを使用して生成された関数の一部を利用し始めるまで（私はそこにいなかった）
http://wwww.asp.net のDAL/BLLソリューションよりもはるかに直感的でクリーンなソリューションを提供するようです。
私は自分でSQLコマンドC＃DALコードジェネレーターを作成することを考えていましたが、ORMはよりエレガントなソリューションのように見えます
クエリのコンパイルとテスト。
ORMのツールが改善されると、コンパイル時のエラーとテストにより、クエリの正確性をより迅速に判断しやすくなります。
クエリをコンパイルすると、開発者がエラーをすばやく見つけるのに役立ちます。右？右。開発者は現在、SQLの文字列またはSQLのようなステートメントではなく、ビジネスオブジェクトまたはモデルを使用してコードでクエリを記述しているため、このコンパイルが可能になります。
.NETで正しいデータアクセスパターンを使用している場合、メモリコレクションに対してクエリロジックを単体テストするのは簡単です。これにより、データベースにアクセスしたり、データベース内のデータを設定したり、完全なデータコンテキストをスピンしたりする必要がないため、テストの実行が高速化されます。[編集]メモリでのテストでは、 難しい課題 を克服することができます。しかし、これらの統合テストは以前よりも簡単に書くことができます。[/編集]
これは、質問が行われた数年前よりも今日では間違いなくより関連性がありますが、それは私の経験があるVisual StudioとEntity Frameworkにのみ当てはまる可能性があります。可能であれば、独自の環境をプラグインします。
95％の時間でSQLを抽象化するので、チームの全員がデータベース固有の非常に効率的なクエリを記述する方法を知る必要はありません。
ここには多くの良い点があると思います（移植性、開発/保守の容易さ、OOビジネスモデリングなど）に焦点を当てます） to ORMを使用して節約できる金額。
一般的なタスク（または今後予定されている大規模なプロジェクト）についていくつかの見積もりを行うと、（できれば！）切り替えが無視できないいくつかの引数を取得できます。
欠点の1つは、ORMでPOJOを更新する必要があることです。主にスキーマ、関係、クエリに関連しています。そのため、モデルオブジェクトに変更を加えることを想定していないシナリオは、プロジェクトまたは白黒のクライアントとサーバー上のものとの間で共有されるためです。そのような場合、2つのレベルに分割する必要があり、追加の作業が必要になります。
私はAndroid開発者であり、ご存じのようにモバイルアプリのサイズはそれほど大きくないので、pure-modelとorm-affected-modelを分離するこの追加の努力は十分な価値がないようです。
私は質問が一般的なものであることを理解しています。しかし、モバイルアプリも汎用的な傘の中に入っています。
コードスミステンプレートを使用した.net層
http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1
同様に生成できるものをコーディングする理由。
変更が発生したときにどれだけの時間/お金を節約できるかを説得し、ORMツールがあなたのためにそれを行うのでSQLを書き直す必要はありません