ストアドプロシージャを使用する場合、ORMを使用できますか？ストアドプロシージャを使用している場合はORMを使用しますか？
EDIT：
私はORMを使用することができた場合は、ORMを使用するためのデータベースagnosticity理由のないこと敗北部分でしょうか？つまり、ストアドプロシージャを使用して特定のデータベースに自分自身をバインドしている場合、ORMを使用する理由は何でしょうか（またはその前提が間違っていますか）。
ORMを使用してストアドプロシージャにアクセスすることは、ORMを使用する最良の方法の1つです。あなたは強く型付けされたオブジェクトを提供しますが、SQLを完全に制御できます。
はい、すべてのメインORMがストアドプロシージャをサポートできます。
ORMでストアドプロシージャを使用する場合は、プロジェクトを特定のデータベースに結合していることを前提としています。しかし、実際にはデータベースプロバイダを変更する必要はないので99％です。この場合、ORMを使用して具体的なDBプロバイダから抽象化するのではなく、ORMの主なタスクであるオブジェクトリレーショナルマッピングタスクORMは元々作られたものです。
より高度なORM機能の多くは、使用するのが難しくなる傾向があります。 iBatisのようなものはストアドプロシージャとの統合が非常に簡単ですが、動的SQLの生成や大規模フィールドの遅延読み込みなどの（N？）Hibernateのようなより複雑なエンジンのより洗練された機能は、
興味深い点が挙げられます。
ORMと比較的単純なクエリを取得したら、なぜストアドプロシージャが必要ですか？ SPはデータベースと緊密に結びついています。 ORMを使用すると、DB固有のコードを多く維持する必要がなくなります。 What は DB固有のものを分離して管理することができます。
私は、ORMは、複雑さを削減し、すべての処理をそれが所属するコードに入れる素晴らしい機会であることを示唆しています。
データベースを使用して、データを保存するのに最適です。
アプリケーションを使用して、データを処理するのに最適な方法を使用します。
私の経験では、ORMに 'CRUD'操作を処理させて、ストアドプロシージャに特殊な作業を任せます。一般的に、 'CRUD'操作にストアドプロシージャを使用することは過剰です.ORMで処理できるようにすると、生産性が大幅に向上します。
はい、ORMがストアドプロシージャに関して提供している機能を調査するのに時間を費やしたいと思います。
ほとんどの場合、厳密に型指定されたオブジェクト/エンティティを返すストアドプロシージャを実行できます。高度なORMを使用すると、CRUDアクションを実行するためのストアドプロシージャをプラグインすることもできます（一般的なクエリ、削除などは動的クエリではなくストアドプロシージャを経由します）。
一般的に、ORMはアドホッククエリを生成し、厳密に型指定されたエンティティを取得するのに適していますが、ストアドプロシージャのサポートが強いと、RDMSのネイティブ機能に一層簡単にアクセスできるようになります特にORMが多くのデータベースエンジンをサポートしている場合は、ORMのクラスの市民になります。
あなたの編集からフォローアップ：
多くの場合、あなたは、私が以前に触れたしかしとしてORMが提供するアドホッククエリエンジンを使用したいと思うでしょう - 時にはあなたはORMから露出していない機能を使用してクエリを実行します。
強く型付けされたエンティティの利点は、データ・リーダー、データ・テーブルなどではなく、通常はドメイン・オブジェクトを持つことを意味するため、非常に有用です。検索したエンティティ内のビヘイビアとロジックをきれいにカプセル化できます。
LightSpeed ORM（およびほとんどの場合）では、エンティティが標準のバインディングインターフェイス、エラーレポートインターフェイス、検証などをサポートするなど、追加の利点のリストは非常に長くなります。クエリ側では、あなたがそれをあなた自身で書くのでなければ、怠惰なローディングなど。
データベース「不確定性」（？）は、ORMを使用する唯一の理由ではありません。ただし、DBとのやりとりの99％、および速度/明瞭度/複雑さのためにストアドプロシージャが必要な1％（または2％または10％など）でDBの独立性を利用することもできます。 DBを変更した場合は、それらを書き直す必要があります。
私は仕事場で多くのネット層を使用しており、私たちは私たちのためにストアドプロシージャを生成させます。これらは基本的なCRUD操作しか処理しませんが、非常に高速で、時間を節約できます。 netTiersではカスタムストアドプロシージャを作成し、これらのプロシージャを使用してデータアクセスコードを生成することもできます。
ORM機能とストアドプロシージャ機能の両方を同時に使用できます。特にORMを使用するとパフォーマンスが低下したり、低レベルのチューニングが必要な場合は、ビジネスロジックにストアドプロシージャを組み込んでください。
私は、あなたの仕事をやり直して問題を解決することからあなたを解放するどんなツールも有効だと思います。 ORMは、たとえSPを使用して要件をよりよく実装しても（爪にハンマーを使用するなど、タスクに適したツールです）、基本的なCRUD操作になるとそのツールのようです。
ポイントは次のとおりです。黒か白か、灰色のスケールだけです。非常に使いにくく、ひどくコード化されたアプリケーションは、DBリソースの誇張された使用を説明するために「DBにとらわれない」という言い訳を使用します。多くの場合、データベースと結びついていることはあまり良くありません。目的は、顧客のITリソースを無駄にせずに最大限の「DBアジノスティック」を得ることです。
極端な「純粋な」アプローチが優れていると言っている人は「古いものと新しいもの」はありません。私は本当にそう信じていない。私は、他のツールと同様に、データアクセスを行うための適切なツールが存在するまで、ORMを使用して「ベスト」（引用符に気づく）アプローチを使用していると考えています。リソースを無駄にし、スケーラビリティと「価値のある人生を生かす」（私がポルトガル語の「vidaútil」に相当する英語表現を忘れてしまった）TIのリソースを減らしている時点で、ORMの中のSPを使用してください。または、言い換えれば、ハンマーが爪用であることを手近に処理するためにSPを使用します。
「強く型付けされたオブジェクト」の場合 – Jagd
強く型付けされた言語の場合はどちらが良いですか。 PHPのようなものを使うときは、あなたのparamsをチェックするコードが必要です。 Thatsは、ORMやコードジェネレータを使用できないことを意味するものではありません。例：PostgreSQL関数のアクセスラッパーを書き、SOAP Webサービスとして公開するコードジェネレーターを開発しました。 PHPはスカラー型のヒントをサポートしていないので、スカラー型のパラメータをチェックするために余分なコードを書く必要がないので、PHPを使用する関数を追加しました（https://github.com/sylnsr/pgfunc2php/blob/master/pgsupport.lib .php） –