ビジネスロジックをストアドプロシージャに入れるかどうか。
「ビジネスロジックをストアドプロシージャにするかどうか」というトピックについては常に議論があります。 ORMツールを使用せず、ビジネスロジックをストアドプロシージャに配置しない場合、ビジネスロジックはどこに配置しますか？
以前のアプリケーションでは、すべてのビジネスロジックをストアドプロシージャのみに置くことを常に好みました。次に、.NETコードから、データアクセスアプリケーションブロックを使用してこれらのストアドプロシージャを呼び出します。 SQLHelperなど。しかし、これは常にシナリオであるとは限りません。だから私はいくつかグーグルをやったが、混乱に終わった.......
何か提案...？
私は実用的なアプローチを採用します。これまで、ビジネスロジックをストアドプロシージャに保持することの主な「利点」はパフォーマンス上の理由（2.5層アーキテクチャ）ですが、ビジネスロジックをBLL層（3/N層）に分離することは、一般的に保守の観点、およびテストが容易（データアクセスのモック/スタブ）。
ただし、LINQ2SQL、EF、NHibernateなどのLINQ対応の.NET ORMSは、クエリプランをキャッシュできるパラメーター化されたSQLクエリを作成し、SQLインジェクションなどでエスケープされるため、3/N層アーキテクチャーへの移行は次のようになると思います。これまで以上に説得力があり、ほとんどのSPROC（特にクエリ中心のSPROC）を完全に回避できます。 .NETのリポジトリパターンは一般にIQueryableを公開し、式ツリーのパラメーターを受け入れ、タイプセーフでありながらテーブルへの柔軟なアクセスを可能にします。 （個人的にSOA=型アーキテクチャでは、BLLを超えてIQueryableを公開しません。つまり、サービス層とプレゼンテーション層は明確に定義されたメソッドのセットで動作するはずです。それ以外の場合、完全にシステムをテストすると、クライアントが発行した任意のクエリがインデックスなどをヒットせずにDBにヒットする可能性があることを知っているので、夜はよく眠れません。）
ただし、適切なサイズのシステムでは、常にいくつかの例外があり、実際にはデータ集約型のコードを、パフォーマンス上の理由からストアドプロシージャとして書き込む必要がある場合があります。これらのインスタンスでは、SPROCを保持し、ORMを介してSPROCを公開しますが、BLLのパススルーメソッドとして関数を公開します。
Java開発者であること私の好みは、ビジネスロジックをBLLに入れることでした（素敵で簡単なソース管理、親しみやすさなど））。
ただし、さまざまなテクノロジー（C＃、Java、Pick（質問しないでください））を使用して多くの分散アプリケーションを持つ大企業で働いた後、ストアドプロシージャを使用することの1つの重要な利点が明らかになりました。
ストアドプロシージャは異なるアプリケーション間で共有できます。
私たちのチームはここでソフトルールを持っています。 T-SQLでビジネスロジックを解決する方が良い場合もあれば、c＃（ビジネスレイヤー）で行う方が簡単な場合もあります。
したがって、実用的なソリューションがあります。私は理論がそれについて時々非常に厳しいことを知っています...しかしそれは理論です:-)
（私の意見では）両方に長所と短所があります：
ストアドプロシージャは、ある種のSQLソース管理（多くの場所では使用しない）を使用しておらず、複数の開発者が作業している場合、悪夢になる可能性があります。誰かがストアドプロシージャを変更し、そのプロシージャを呼び出すコードを更新するのを忘れて、それを知る前に、未処理の例外（パラメーター数の不一致など）をスローするサイトを構築して展開したところです。
一方、ストアドプロシージャを使用すると、特定の状況でバグをすばやく修正できます。ストアドプロシージャにバグがある場合は、それを修正するだけで完了です。 ORMのバグ修正には再構築が必要です。ビルドプロセスによっては、この処理に時間がかかる場合があります。
「ビジネスロジック」は少しあいまいな用語です。つまり、単一の定義はありません。経験則では、可能な場合は階層間の通信を最小限に抑えます。したがって、行を挿入する前に、空白の顧客名をサーバーに送信して確認する必要はありません。
ルールがデータベースの読み取りに基づいている場合があります。アカウント1からアカウント2に送金したいとします。両方のアカウントを読み取り、それらが良好な状態にあり、アカウント1の金額が十分であることを確認する必要があります。この場合、クライアント（ここではBLである）はこのプロセスのためにデータベース層に3回の呼び出しを発行する必要がないため、サーバーがこのルールのより良い候補です。
もちろん、データベースに依存しないソリューションが必要な場合は、CRUDのみにストアードプロシージャを作成します（使用する場合）。
ビジネスロジックは常にビジネスロジックレイヤーに配置します。ストアドプロシージャに入れると、RDBMSを変更すると失われます。
ロジックは常に次の理由でBLLにある必要があります。
- 適切にテストできます
- SQL 20XXが廃止され、最新バージョンに変更する必要がある場合は、コードを書き直す必要はありません。
- 人々はその場で変更を加えるように誘惑されません（これはSPの議論として提唱されているようです）
- 私の経験では、SPは、特に数世代のメンテナンス/変更後の開発者エラーの単一の最大のポイントです。
SPがX行を超えると、意図したとおりに機能しなくなることを明記した法律があるはずです。
選択した言語で実装されたすべてのビジネスロジックを含むサービスレイヤーを作成し、データベースをクエリにのみ使用します。私たちの目標は、さまざまなデータベース実装を備えたアプリケーションを提供するCOTSソリューションを作成することであるため、このアプローチは、私たちによってある程度義務付けられています。 Hibernateは、このような状況で私たちにとって命の恩人であることが証明されています。
このアプローチの最大の利点は、データベースの移植性を除いて、1回の検索ですべての回答を見つけることができることです。
また、フォーラムへの回答もいくつかありますが、フォーチュン100の保険会社に勤務している友人がいて、選択したデータベースが変わったため、3年間で2回データベースの変換を行っています。
私の限られた経験では、ストアドプロシージャやその他のデータベース機能を使用してデータの整合性を維持することを好みます。たとえば、2つのアカウント間で送金を実装する場合、ストアドプロシージャを記述します。複数のアプリケーション言語を使用できるのは貴重です。