ユーザーが入力したいくつかの数字に基づいて、ボタンをクリックしたときに別の番号（単純化したもの）を与えるWebアプリケーションがあるとします。すべてのデータはSQLサーバーに格納されます。これで、ビジネスアクセスレイヤーに必要なデータをすべて取得し、そこで計算を実行できます。または、データベース内の計算でprocを保存し、その結果をアプリケーションに送信します。私はそれをはるかに容易に見つけるので、私は強く後者を好む。しかし、一部の人々は、すべてのビジネスロジックは、アプリケーションのビジネス層にある必要がありますと主張することがあります。私はアプリ内にビジネスロジックがあれば、それがビジネス層に属していると感じます。しかし、アプリケーションにデータ関連のビジネスロジックを持つ必要はありません。asp.netアプリケーションのビジネスレイヤー
専門家は何をお勧めしますか？
あなたの質問に言い換えると、「私はビジネスロジックをtsqlまたはc＃に入れるべきですか？」と質問していると思います。
個人的には、私は強くC＃（またはあなたが使っているものならvb.net）を勧めます。プログラミングツールとして、tsqlよりもはるかに強力です。そして、私が力を言うとき、私は理解しやすく、論理的で、組織化された自己文書化コードを書く力を意味します。もっと重要なことは、維持しやすいということです。抽象クラスやインタフェースなどのオブジェクト指向のテクニックを使用すると、再利用可能なコードだけでなく、容易に追跡可能なビジネスロジックを実行することができます。これは、格納されたprocsでシミュレートすることができますが、あなたはそれを実装するためにフープを突き抜けてしまい、問題があるときにそれをトレースします。
コードリポジトリは、SQL Serverよりもはるかに簡単にVSとの統合を可能にするために構築されています。また、ローカルで実行するには大きすぎるデータベースに物事を集中させると、開発者のC＃コードのローカル作業コピー。
当然、単一の開発者シナリオでは、誰もこのアプリケーションで作業しない場合、他のツールと比較して開発者の快適さと比較して、コラボレーションと変更管理に関する考慮事項は薄いです。
最後に、c＃が豊富な言語機能を提供しているからといって、誰もそれらを使用していないからです。私は1000行のC＃メソッドを簡単に1000行のprocを書き込むことができるように書くことができます（そして持っています！）。
希望すると、 ローレンス
いずれかを実行できます。これまでにデータベースに触れずに番号を渡したければ、その計算をビジネス層で行うことが望ましいでしょう。ビジネス層は、ストアドプロシージャよりもデバッグが容易で、単体テストが可能なため、良い場所です。