なぜORMを使用する必要があるのですか？[閉まっている]

ORMを管理/クライアントに使用する理由の「長所」をやる気にさせるとしたら、その理由は何でしょうか？

回答ごとに1つの理由を試して、投票されたものを最良の理由として確認できるようにします。

データアクセスをより抽象的で移植性の高いものにします。ORM実装クラスはベンダー固有のSQLの記述方法を知っているので、その必要はありません。

ORMを使用する最も重要な理由は、豊富なオブジェクト指向のビジネスモデルを保持しながら、それを保存し、リレーショナルデータベースに対して効果的なクエリをすばやく作成できるようにするためです。私の観点からは、優れたORMが提供できる高度なタイプのクエリ以外の他の生成されたDALと比較したときに、優れたORMがもたらす実際の利点はわかりません。

私が考えているクエリの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は、他の誰かが生成された関数の一部を利用するために（私がそこにあるとは思いもよらなかった）使用するまで、（私が作成したものに対して）うまく機能していました。

それはからのDAL / BLLソリューションよりもはるかに直感的でクリーンなソリューションを提供するように見えます http://wwww.asp.netの。

独自のSQLコマンドC＃DALコードジェネレーターを作成することを考えていましたが、ORMはよりエレガントなソリューションのように見えます

クエリのコンパイルとテスト。

ORMのツールが改善されると、コンパイル時のエラーとテストにより、クエリの正確性をより迅速に判断することが容易になります。

クエリをコンパイルすることで、開発者はエラーをより早く見つけることができます。正しい？正しい。このコンパイルが可能になるのは、開発者がSQLの文字列やSQLのようなステートメントではなく、ビジネスオブジェクトまたはモデルを使用してコードでクエリを記述しているためです。

.NETで正しいデータアクセスパターンを使用している場合、メモリコレクション内でクエリロジックをユニットテストするのは簡単です。データベースにアクセスしたり、データベースにデータを設定したり、本格的なデータコンテキストを起動したりする必要がないため、テストの実行速度が向上します。メモリ内のテストは提示することができます、克服するのが難しい課題をするます。しかし、これらの統合テストは、以前よりも簡単に記述できると思います。[/ EDIT]

これは、質問が尋ねられた数年前よりも今日の方が明らかに関連性が高いですが、それは、私の経験が存在するVisual StudioとEntity Frameworkにのみ当てはまる可能性があります。可能であれば、独自の環境をプラグインしてください。

SQLを95％離れた場所に抽象化して、チームの全員が超効率的なデータベース固有のクエリを作成する方法を知る必要があるわけではありません。

ここには多くの良い点があると思います（移植性、開発/保守の容易さ、OOビジネスモデリングに焦点を当てるなど）は、クライアントまたは管理を説得しようとするとき、すべてを使用することで節約できる金額に要約されます。 ORM。

典型的なタスク（または今後発生する可能性のあるさらに大きなプロジェクト）の見積もりを行うと、（うまくいけば！）無視するのが難しい切り替えに関するいくつかの引数が得られます。

コードスミステンプレートを使用した.net層

http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1

同様に生成できる何かをコーディングする理由。

変更が行われたときに節約できる時間と費用を納得させ、ORMツールが代わりにSQLを作成するため、SQLを書き直す必要がありません。

短所の1つは、ORMがPOJOで更新を必要とすることです。主にスキーマ、リレーション、クエリに関連しています。したがって、モデルオブジェクトを変更することを想定していないシナリオは、プロジェクトまたはb / wクライアントとサーバー上で共有されているためと考えられます。そのため、このような場合は、2つのレベルに分割する必要があり、追加の作業が必要になります。

私はAndroid開発者です。ご存知のように、モバイルアプリのサイズは通常それほど大きくありません。そのため、pure-modelとorm-affected-modelを分離するこの追加の作業は、十分に価値があるとは思えません。

私はその質問が一般的なものであることを理解しています。しかし、モバイルアプリも一般的な傘の中にあります。