メンバーの複雑な計算を行うアプリケーションがあります。各メンバーは、プロファイルにリンクされた米国の複数の州を持つことができます。州ごとに、メンバーが完了するコースごとに異なる計算が行われます。
今のところ、DB (SQL Server 2008) で計算を実行してから、アプリ層にデータを送り返し、そこで履歴を確認し、各コースの証明書をダウンロードしています。
私はビジネス ロジック層を持っていますが、そこではあまり起こりません。これはよく聞かれることだと思いますが、これらの計算をどこで実行する必要があると思いますか: ビジネス レイヤーまたはデータベース? 行ったり来たりです！！
私は基本的にSQLServerで次のことを行います。
データの多くの合計、カウント、平均化などを行い、単一の値のみを返します。列を要約するだけで、大量のデータを中間層に転送しても意味がありません。
多くの行/セットベースの操作を行います。大量のデータをコピー、挿入、更新する必要がある場合も、すべてのデータを中間層にドラッグしてからサーバーに送り返すことには意味がありません。サーバー上で最初からやり直してください。また、T-SQLは、中間層のどの操作よりも、セットベースの操作（データのシャッフルなど）の処理が大幅に高速です。
簡単に言うと、どうしても必要な場合を除いて、クライアント/中間層/ビジネスレイヤーに大量のデータを送信しないようにしてください（データベースに保存されているファイルをダウンロードする場合や、200行が本当に必要な場合など）。アプリ内のオブジェクトに具体化され、どこかに表示されたり、操作されたりします）
見落とされがちな機能の1つは、データベーステーブルの計算列です。これらの列は、注文の合計と税金を合計し、総計に送料を計算するのに非常に優れています。または、名前と名前を表示名にまとめるのに最適です。 。これらの種類のものは、実際にはビジネスロジックレイヤーでのみ処理するべきではありません。データベースで直接処理する場合は、データベーステーブルを調べてSQL Serverのデータを確認するときに、これらの「計算された」値も利用できます。管理スタジオ..。
私はそれを中間層/ビジネスロジック層に入れます
広範なロジックチェック、文字列解析、パターンマッチングなどが必要な場合。T-SQLはそれらのことを嫌います
データを検証するためにデータを取得するためにWebサービスを呼び出すなどの必要がある場合、またはそのようなもの
（厳密な「アトミック」データベース操作ではなく）より多くのビジネスロジック操作が必要な場合
しかし、これらは単なる「大まかな」ガイドラインです。これは常に各ケースの設計上の決定であり、厳密なルールは信じていません。マイレージはケースごとに異なる可能性があるため、手元の特定のタスクに最適なアプローチを1つ選択してください。
データベース (ストアド プロシージャ) 内にビジネス ロジック コードを持たないことが役立ちます。アーキテクチャに正しく適合するように、アプリケーションに直接配置する方がはるかに優れています。この SQL コードにはビジネス ロジックが含まれており、問題はありません。(ただし、sprocs にデータやメンテナンス関連のコードを含めることには何の問題もありません)。
ビジネス ロジック レイヤーがあまり機能しておらず、SQL Server から呼び出し元にデータを渡すだけの場合は、まったく必要ない可能性があります。
ビジネス ロジック層は、重労働を行うためのものではありません。その目的は、主題の言語でエンティティを抽象化することです。したがって、ビジネス層を使用して、その領域で動作する必要があるすべての層/アプリケーションに対して、共有された一貫したアプローチを提供できます。
要点を明確にするためにオーバー エンジニアリングを行う場合、最終的な目標は、ビジネス ロジック層が、そのサブジェクト スペースで動作するすべてのアプリケーションに対して組織全体で使用されることです。つまり、サービスなどに包まれています。
これやあれを行う小さなアプリの現実の世界では、ビジネス ロジック レイヤーが付録のように感じることがあります。秘訣は、ユースケースはビジネスレイヤーに対するテストとして実装する必要があることも覚えておくことです。これにより、パブリックインターフェイスがどのように見えるべきかを考える別の方法が得られます。
ビジネス ロジック層がどのように作業を完了するかは、それを呼び出すアプリケーションの部分から隠されている必要があります。
したがって、これらの計算がビジネス ロジック層で適切に表現される限り、最も効率的な方法 (SQL など) でデータを計算することはまったく問題ありません。