ORMを使用せず、ストアドプロシージャを好む場合

PetaPoco micro-ORMを使用しています。ORMツールを使用してデータベースを操作するのは確かに非常に簡単で安全ですが、私が嫌いなのは余分なコードだけです。以前はほとんどのコードをデータベース自体に配置し、ストアドプロシージャ、トリガーなど、RDBMSのすべての機能を使用していました。

ストアドプロシージャ/トリガーでORMを使用しない場合、またはその逆の場合を知りたいです。

ORM（オブジェクトリレーショナルマッピング）は、ストアドプロシージャと相互に排他的ではありません。ほとんどのORMはストアドプロシージャを利用できます。ほとんどのORMは、必要に応じてストアドプロシージャを生成します。したがって、問題はどちらでもありません。

ORMは（パフォーマンスの点で）許容できないSQLを生成する可能性があり、手作りのSQLでそのSQLをオーバーライドしたい場合があります。これを実現する方法の1つは、SP（ストアドプロシージャ）を使用することです。

DotNetでは、次の場合にストアドプロシージャを使用しないでください。

• ストアドプロシージャに慣れていない場合（あなたの場合ではなく、完全を期すために含まれています）。

• 複雑なレイヤーを導入したくない場合は、プロジェクトを複雑にします。

• 異なるデータベースで動作するアプリケーション、または複数のデータベースサーバー間で複製する必要があるアプリケーションを作成しています（この最後の制限は一部のデータベースにのみ適用される場合があります）。

トリガーはORMと比較されないことに注意してください。トリガーは、アプリケーションコードにはない方がよい機能を実行します（データベース間でのデータのロギングや同期など）。

セキュリティなどのさまざまな理由（たとえば、SQLインジェクションを防ぐため）および要求される速度のために、コードではSQLよりもストアドプロシージャの使用を好む人もいます。ただし、これは多少議論の余地があり、詳細な議論が必要です。

ORMがストアドプロシージャを生成できず、大規模なシステムを作成する必要がある場合は、ケースに基づいて追加のハンドコーディングを重み付けする必要があります。

多くの場合、 ORMデータベースは、ORMを提供するために存在していることを前提としています。しかし、通常、データベースは会社にサービスを提供するために存在し、複数の言語で書かれた何百ものアプリがヒットする場合があります。

ただし、ストアドプロシージャを呼び出せないORMを使用している場合は、「ORMとストアドプロシージャ」の場合にすぎません。それ以外の場合は、ビジネスロジックをコーディングする場所を決定する場合です。

ビジネスロジックをコーディングする場所はどこでも、どのアプリケーションが変更を行ったかに関係なく、データベースが一貫性のある状態から別の一貫性のある状態に確実に変更されるようにします。したがって、実際には2つの選択肢しかありません。データベースに1回コーディングするか、「侵入できない」データアクセスレイヤーに1回コーディングするだけです。

「不可解な」DALを使用する場合は、dbmsコマンドラインインターフェイスに注意してください。

単純なクエリ-> ORM

複雑なクエリ->ストアドプロシージャ

トリガーは、記録の不変条件として使用するか、重要なビジネスルールであるIMHOで構成する必要があります。

組織の問題：

1. 「アクション」ごとではなく、テーブルごとにアクセス許可を設定する必要があります（SPを意味します）
2. ソリューションのロジックを変更するには、アプリ内のコードを変更し、ネットワーク経由でクライアントに再配布する必要があります

同意しない。ORMクエリは、SQLを知っているよりもORMをよく知っている場合にのみ簡単です。ORMを使用すると、コードがはるかに多くなり、IMOを維持するのがはるかに難しくなります。ORMの恩恵を受けるのは、ORMを販売している会社（Microsoftなど）の株主のみです。