ストアドプロシージャにビジネスロジックを配置するかどうか。

「ビジネスロジックをストアドプロシージャに入れるかどうか」というトピックについては常に議論があります。ORMツールを使用せず、ビジネスロジックをストアドプロシージャに入れないことにした場合、どこにビジネスロジックを入れますか？

以前のアプリケーションでは、すべてのビジネスロジックをストアドプロシージャにのみ配置することを常に好みました。次に、.NETコードから、データアクセスアプリケーションブロックを使用してこれらのストアドプロシージャを呼び出します。SQLHelperなど。しかし、これは常にシナリオになることはできません。だから私はいくつかのグーグルをしましたが、混乱してしまいました.......

何か提案...？

私は実用的なアプローチを採用します-歴史的に、ストアドプロシージャにビジネスロジックを保持する主な「メリット」はパフォーマンス上の理由（2.5層アーキテクチャ）ですが、ビジネスロジックをBLL層（3 / N層）に分離することは一般的にメンテナンスの観点、およびテストが容易です（データアクセスのモック/スタブ）。

ただし、LINQ2SQL、EF、NHibernateなどのLINQ対応の.NET ORMSが、SQLインジェクションなどのためにクエリプランをキャッシュできるエスケープされたパラメーター化されたSQLクエリを作成することを考えると、3 / N層アーキテクチャへの移行はかつてないほど魅力的であり、ほとんどのSPROC（特にクエリ中心のSPROC）は完全に回避できます。.NETのリポジトリパターンは通常、IQueryableを公開し、式ツリーのパラメーターを受け入れて、タイプセーフでありながらテーブルへの柔軟なアクセスを可能にします。（個人的にSOAタイプのアーキテクチャでは、IQueryableをBLL以外に公開しません。つまり、サービス層とプレゼンテーション層は明確に定義された一連のメソッドで動作するはずです。理由は、そうしないとシステムを完全にテストできないためです」

ただし、まともなサイズのシステムでは、常にいくつかの例外があります。パフォーマンス上の理由から、実際にはデータを集中的に使用するコードをストアドプロシージャとして記述する必要がある場合があります。これらのインスタンスでは、SPROCを保持し、ORMを介してSPROCを公開しますが、BLLのパススルーメソッドとして関数を公開します。

Java開発者としての私の好みは、BLLにビジネスロジックを入れることでした（素敵で簡単なソース管理、親しみやすさなど）。

ただし、さまざまなテクノロジー（C＃、Java、Pick（尋ねない））を使用して多くの分散アプリケーションを使用する大企業で働いた後、ストアドプロシージャを使用することの重要な利点が明らかになりました。

ストアドプロシージャは、異なるアプリケーション間で共有できます。

私たちのチームはここでソフトルールを持っています。T-SQLでビジネスロジックを解決する方が良い場合もあれば、c＃（ビジネスレイヤー）で簡単に解決できる場合もあります。

したがって、実用的な解決策があります。より適切な場所に配置してください。私は理論が時々それについて非常に厳格であることを知っています...しかしそれは理論です:-)

両方に長所と短所があります（私の意見では）。

ストアドプロシージャは、何らかのSQLソース管理（多くの場所では使用していません）を使用しておらず、複数の開発者が作業している場合、悪夢になります。誰かがストアドプロシージャを変更し、そのプロシージャを呼び出すコードの更新を忘れることができます。それを知る前に、未処理の例外（パラメーターカウントの不一致など）をスローするサイトを構築して展開したばかりです。

一方、特定の状況でストアドプロシージャを使用すると、バグをすばやく修正できます。ストアドプロシージャにバグがある場合、それを修正するだけで完了です。ORMのバグ修正には再構築が必要です。ビルドプロセスによっては、これは非常に時間がかかる/面倒な場合があります。

私たちは常にビジネスロジックをビジネスロジック層に配置します。ストアドプロシージャに配置すると、RDBMSを変更すると失われます。

「ビジネスロジック」は少し曖昧な用語です。つまり、単一の定義はありません。経験則として、可能な場合は階層間の通信を最小限に抑えます。したがって、行を挿入する前に、空の顧客名をサーバーに送信して確認する必要はありません。

ルールがデータベースの読み取りに基づいている場合があります。アカウント1からアカウント2に送金する場合、両方のアカウントを読み、アカウントが良好な状態であり、アカウント1の金額が十分であることを確認する必要があります。この場合、クライアントは（ここではBLである）このプロセスのためにデータベース層に3つの呼び出しを発行する必要がないため、サーバーはこのルールのより良い候補です。

もちろん、データベースに依存しないソリューションが必要な場合は、CRUD専用のストアドプロシージャを作成します（使用されている場合）。

次の理由により、ロジックは常にBLLに含まれている必要があります。

• 適切にテストできます
• SQL 20XXが廃止され、最新バージョンに変更する必要がある場合、コードを書き換える必要はありません。
• 人々はその場で変更を加えようとはしません（SPの議論として提案されているようです）
• 私の経験では、SPは、特に数世代の保守/変更後の開発者エラーの最大のポイントです。

SPの長さがX行を超えると、意図したとおりに機能しないことを示す法律があるはずだと思います。

選択した言語で実装されたすべてのビジネスロジックを含むサービスレイヤーを作成し、クエリにのみデータベースを使用します。私たちの目標は、さまざまなデータベース実装を備えたアプリケーションを提供するCOTSソリューションを作成することであるため、このアプローチは私たちによって一種の義務付けられています。Hibernateは、このような状況で私たちにとって命の恩人であることが証明されています。

このアプローチの最大の利点は、データベースの移植性は別として、1回の検索ですべての答えを見つけることができることです。

また、フォーラムへのいくつかの回答にもかかわらず、会社の選択したデータベースが変更されたため、3年間で2つのデータベース変換を行ったフォーチュン100の保険会社で働いている友人がいます。

私の限られた経験では、ストアドプロシージャやその他のデータベース機能でデータの整合性を維持することを好みます。たとえば、2つのアカウント間で資金の移動を実装する場合、ストアドプロシージャを作成します。複数のアプリケーション言語を使用できることは貴重だと思います。