假設您有一個基於用戶輸入的某些數字的Web應用程序，當他/她單擊一個按鈕時，會給他另一個數字（超過簡化）。所有的數據都存儲在SQL服務器中。現在，我可以將所有必需的數據提供給業務訪問層並在那裏進行計算。或者在數據庫中進行存儲proc的計算並將結果發送給應用程序。我非常喜歡後者，因爲我覺得它更容易。但有些人可能會認爲所有的業務邏輯必須位於應用程序的業務層。我覺得如果應用中有任何業務邏輯，它就屬於業務層。但是您不必在應用中擁有與數據相關的業務邏輯。asp.net應用程序中的業務層
專家會推薦什麼？
如果我可以改一下你的問題，我想你會問：「我應該把我的業務邏輯在TSQL或C＃？」
就個人而言，我強烈建議C＃（或vb.net，如果這是你使用的是什麼）。作爲編程工具，它比tsql提供了更多的功能。當我說權力時，我的意思是寫出易於理解，合乎邏輯，組織良好的自我記錄代碼的能力，更重要的是易於維護。面嚮對象的技術（如抽象類和接口）允許您創建不僅可重用的代碼片段，還允許您實施易於追蹤的業務邏輯。這可以通過存儲過程來模擬，但是最終你會通過循環來實現它，然後在出現問題時追蹤它。
與SQLserver相比，代碼庫更容易與VS集成，並且更改管理甚至本地開發環境維護變得更加困難，因爲當事情集中在一個數據庫太大而無法在本地運行而不是更新時一個開發人員本地C＃代碼的工作副本。
當然，在一個單一的開發情況下，當沒有人會永遠在這個應用程序，協同工作和變更管理方面的考慮相比，開發人員的舒適性與TSQL VS任何其他工具蒼白。
最後，只是因爲C＃提供了豐富的語言功能，不是每個人都使用它。我可以（也有!!）寫1000行C＃方法，就像我可以寫1000行存儲過程一樣容易。
希望這會有幫助， Lawrence
你也可以做。如果您想要在不觸摸數據庫的情況下發送數字，那麼您需要在業務層中進行計算。業務層是一個好地方，因爲它比存儲過程更易於調試，並且可以進行單元測試。