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

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

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

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

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

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

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

????? 最后，幫公司發(fā)個招聘啟示：

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

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

業(yè)務邏輯層與儲存過程的疑惑