業務邏輯在一個系統中可放的地方很多，有的人選擇放在存儲過程中，有的人會選擇放在業務組件中，這些方式都可以進行業務邏輯的判斷。既然提供了這些方式都可以實現業務邏輯的判斷，就證明它們存在的合理性。就像在設計的過程中，很多人會將進行條件選擇語句封裝到不同的類的重構，以滿足設計中的”開－閉“原則，這樣做有他的道理。但并不是說以后就不用條件轉移語句了，要不開發語言怎么會支持條件轉移語法呢。我們要根據具體的情況選擇是否重構，比如我們只需要創建一個對象，如果進行重構，試想得建多少的類啊，維護起來頭不夠大啊。

????????? 那是不是在項目開發中就可以任選一種方式呢？當然是不可取，很多都是依據具體情況而定的，只有在具體情況中才能說好還是不好。打個比方，一個項目，好的設計需要1個月，差的設計只要10天，此時你應該選擇哪一個？更多的人會選擇花1個月的設計，因為大家對設計的追求。但是如果這個項目只給了1個月時間，你又該如何選擇呢？當然，這個例子不是很確切，但只想說明一點：適合才是正確的。將業務寫入存儲過程，可以找出很多的理由推翻這種做法，也能找很多的理由贊成這種做法，那都是站在不同的項目環境看這個問題。對于小型的項目，邏輯相對簡單，為了快速，減少開發規模，將業務邏輯寫入存儲過程，是比較好的一種方式；對于大型項目，考慮業務邏輯的復雜性，將業務邏輯封裝到組件中是一種相對較好的方式。相對存儲過程的修改、維護和部署，是否要更安全和方便呢？同時，將業務邏輯寫入存儲過程，會增加數據庫服務器的負荷，極端一點有一個很復雜的邏輯，需要讀取很多的數據進行比較，很多人并發訪問，那我們是否應該考慮一下數據庫服務器的負擔，是否可以將一部分工作放在客戶端或者應用服務端？。要說的太多了，不過要說明的還是一點：適合才是正確的！
?

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1504043