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

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

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