業務邏輯在一個系統中可放的地方很多,有的人選擇放在存儲過程中,有的人會選擇放在業務組件中,這些方式都可以進行業務邏輯的判斷。既然提供了這些方式都可以實現業務邏輯的判斷,就證明它們存在的合理性。就像在設計的過程中,很多人會將進行條件選擇語句封裝到不同的類的重構,以滿足設計中的”開-閉“原則,這樣做有他的道理。但并不是說以后就不用條件轉移語句了,要不開發語言怎么會支持條件轉移語法呢。我們要根據具體的情況選擇是否重構,比如我們只需要創建一個對象,如果進行重構,試想得建多少的類啊,維護起來頭不夠大啊。
????????? 那是不是在項目開發中就可以任選一種方式呢?當然是不可取,很多都是依據具體情況而定的,只有在具體情況中才能說好還是不好。打個比方,一個項目,好的設計需要1個月,差的設計只要10天,此時你應該選擇哪一個?更多的人會選擇花1個月的設計,因為大家對設計的追求。但是如果這個項目只給了1個月時間,你又該如何選擇呢?當然,這個例子不是很確切,但只想說明一點:適合才是正確的。將業務寫入存儲過程,可以找出很多的理由推翻這種做法,也能找很多的理由贊成這種做法,那都是站在不同的項目環境看這個問題。對于小型的項目,邏輯相對簡單,為了快速,減少開發規模,將業務邏輯寫入存儲過程,是比較好的一種方式;對于大型項目,考慮業務邏輯的復雜性,將業務邏輯封裝到組件中是一種相對較好的方式。相對存儲過程的修改、維護和部署,是否要更安全和方便呢?同時,將業務邏輯寫入存儲過程,會增加數據庫服務器的負荷,極端一點有一個很復雜的邏輯,需要讀取很多的數據進行比較,很多人并發訪問,那我們是否應該考慮一下數據庫服務器的負擔,是否可以將一部分工作放在客戶端或者應用服務端?。要說的太多了,不過要說明的還是一點:適合才是正確的!
?
????????? 那是不是在項目開發中就可以任選一種方式呢?當然是不可取,很多都是依據具體情況而定的,只有在具體情況中才能說好還是不好。打個比方,一個項目,好的設計需要1個月,差的設計只要10天,此時你應該選擇哪一個?更多的人會選擇花1個月的設計,因為大家對設計的追求。但是如果這個項目只給了1個月時間,你又該如何選擇呢?當然,這個例子不是很確切,但只想說明一點:適合才是正確的。將業務寫入存儲過程,可以找出很多的理由推翻這種做法,也能找很多的理由贊成這種做法,那都是站在不同的項目環境看這個問題。對于小型的項目,邏輯相對簡單,為了快速,減少開發規模,將業務邏輯寫入存儲過程,是比較好的一種方式;對于大型項目,考慮業務邏輯的復雜性,將業務邏輯封裝到組件中是一種相對較好的方式。相對存儲過程的修改、維護和部署,是否要更安全和方便呢?同時,將業務邏輯寫入存儲過程,會增加數據庫服務器的負荷,極端一點有一個很復雜的邏輯,需要讀取很多的數據進行比較,很多人并發訪問,那我們是否應該考慮一下數據庫服務器的負擔,是否可以將一部分工作放在客戶端或者應用服務端?。要說的太多了,不過要說明的還是一點:適合才是正確的!
?
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1504043
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
