?? 很慚愧，做了兩年的軟件開發，那些業務邏輯該放在業務邏輯層，哪些業務邏輯該用存儲過程來實現，心里一直是一團漿糊。從大學開始，我就對SQL語句有著說不出的討厭，所以我對數據庫技術知之甚少，所以要實現某個功能，首先想到的就是抽象業務流程，設計接口，抽象類型，提取核心流程做基礎設計，最后才考慮數據的存儲，所以我建表幾乎是從來不考慮滿足那個什么三范式的。類型到數據表的相互映射，也是中規中矩的自己造輪子，利用特性、反射，從不用成熟的ORM框架。

???? 因為做的項目較小，數據處理也不是很多，所以上述做法也行得通，而且自我感覺良好。但是我最近仔細思考了我做過的項目，幾乎所有的業務都是對數據的處理，歸根結底還是對數據的枚舉和對數據的修改。數據庫的存儲工作不是能以最好的性能滿足對數據的枚舉和對數據的修改么？而且存儲過程的優點很多：

• 減少網絡帶寬,按理論存儲過程會提高性能.
• 無需重新編譯,更改后即可運行,無需重新編譯代碼
• 由專門的dba寫的sql語句更高效
• 安全性(在傳輸用戶名密碼時,可防止注入等情況)

???? 后來的幾個項目我又改變了風格，純粹用存儲過程來開發，中間的業務邏輯層幾乎純粹成了數據傳遞層，完全拋棄了模型類和場景類，從前端到后臺都是DataTable過來過去，中間用了微軟的強類型表。項目也照樣完成得很好，而且速度奇快。當然，存儲過程也有他的缺點：

• 依賴于數據庫廠商,難以移植(當一個小系統發展到大系統時,對數據庫的要求也會發生改變)
• 業務邏輯大的時候,封裝性不夠,難調試難以維護
• 復雜的應用用存儲過程來實現，就把業務處理的負擔壓在數據庫服務器上了。沒有辦法通過中間層來靈活分擔負載和壓力.均衡負載等

????? 但我們又有多少項目需要移植數據庫呢，又有多少業務邏輯是存儲過程解決不了呢，又有多少項目是讓數據庫系統滿負荷運行呢？可能我是菜鳥，但我做的幾十個項目中，真的極少遇到上述的情況。

????? 兩廂對比，迷糊了，暈菜了，我潛意識里知道存儲過程實現所有的業務是不好的，而且存儲過程的IDE沒有“重構”“查找所有引用”這樣貼心的小功能，維護確實很惱火。但我又說不出這東西究竟差在那些大地方，求園子里面的達人指點指點呀，你們的業務邏輯是如何在業務邏輯層實現的呀，求解惑……

????? 最后，幫公司發個招聘啟示：

????? 成都九洲電子信息是一家有軍工背景的企業，在物聯網、 RFID方面有核心競爭力，現在因為項目需要，大量招聘 .Net開發人員，月薪4000-8000。詳情請見：

http://job.cnblogs.com/offer/13828/

業務邏輯層與儲存過程的疑惑