前言

《Springboot中如何優(yōu)雅的寫好controller層代碼》一不小心進(jìn)入了全站綜合熱榜，收到了大家熱情的支持，非常感謝大家，同時說明大家都有同樣一個訴求，想好好寫代碼，不想給別人挖坑，爭取可以早點(diǎn)下班。今天我再接再厲，再和家大家分享一下對如何寫好service層代碼一點(diǎn)粗略看法，歡迎大家點(diǎn)評指正。

成都網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)公司、微信開發(fā)、微信小程序開發(fā)、集團(tuán)成都企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。核心團(tuán)隊(duì)均擁有互聯(lián)網(wǎng)行業(yè)多年經(jīng)驗(yàn)，服務(wù)眾多知名企業(yè)客戶；涵蓋的客戶類型包括：履帶攪拌車等眾多領(lǐng)域，積累了大量豐富的經(jīng)驗(yàn)，同時也獲得了客戶的一致贊揚(yáng)！
如何優(yōu)雅寫好Service層代碼

其實(shí)如果controller層規(guī)劃好了，完成了入?yún)?shù)據(jù)的統(tǒng)一校驗(yàn)，返回結(jié)果統(tǒng)一封裝，那么servcie層就相對簡潔清爽多了，基本上就是純純的業(yè)務(wù)邏輯。具體的業(yè)務(wù)功能千變?nèi)f化，但是大致的套路都差不多。

在當(dāng)下的很多項(xiàng)目建設(shè)當(dāng)中，微服務(wù)架構(gòu)、分布式部署、前后端分離，基本上屬于標(biāo)配了，所以在service層的業(yè)務(wù)邏輯和傳統(tǒng)的單體項(xiàng)目相比，除了會調(diào)用Dao層的數(shù)據(jù)庫操作方法，也會調(diào)用一些遠(yuǎn)程的方法。以電商項(xiàng)目為例來說，調(diào)用訂單服務(wù)接口進(jìn)行下單操作時，要先確認(rèn)是否有庫存，就會在訂單服務(wù)接口內(nèi)調(diào)用遠(yuǎn)程的庫存服務(wù)接口，確認(rèn)是否有庫存，如果確認(rèn)還有庫存，繼續(xù)調(diào)用訂單服務(wù)的dao接口進(jìn)行下單的業(yè)務(wù)邏輯，并調(diào)用庫存服務(wù)的減庫存接口，進(jìn)行扣減庫存。

因此，如何優(yōu)雅寫好service層代碼，基本就分成了兩塊：

• 如何優(yōu)雅調(diào)用本地dao接口

• 如何優(yōu)雅調(diào)用遠(yuǎn)程服務(wù)接口

優(yōu)雅調(diào)用本地dao接口

本地的dao接口調(diào)用其實(shí)相對簡單的多，根據(jù)實(shí)際業(yè)務(wù)需要去調(diào)用即可。唯一需要注意的地方就是關(guān)于異常的處理，不管是增加、刪除、修改、查詢，盡量不要在dao調(diào)用上去try catch。為什么呢？沒有必要，因?yàn)镾QL寫正確了，大概率是不會有異常的；如果在執(zhí)行前SQL寫的不正確，啟動的時候就會報異常了，再去try catch捕獲異常，有些畫蛇添足。同樣的道理，如果數(shù)據(jù)庫掛了，連接失敗，即便是捕獲了異常，依然什么也做不了。所以這樣的try catch沒有意義，沒有意義的事的又何必去做呢。反而，如果try catch中捕獲了異常，那么你就必須進(jìn)行有意義的異常處理，僅僅打印個日志不算處理，有意義的處理是指通過個異常處理可以保證后續(xù)程序的正確執(zhí)行，因?yàn)楫惓５恼_處理和事務(wù)回滾也有關(guān)系。很多時候，如果你發(fā)現(xiàn)，由于業(yè)務(wù)發(fā)生異常時應(yīng)該數(shù)據(jù)回滾但卻沒有回滾，十有八九和不當(dāng)?shù)漠惓Ｌ幚碛嘘P(guān)。

如果在SQL執(zhí)行過程中異常，且當(dāng)前SQL執(zhí)行異常不希望影響后續(xù)業(yè)務(wù)邏輯，那么可以捕獲。另外處理異常的時候，如果實(shí)在處理不了就向上拋，或者進(jìn)行一些業(yè)務(wù)處理，以保證異常不會影響后續(xù)業(yè)務(wù)程序的正常執(zhí)行。

大批量數(shù)據(jù)的寫

關(guān)于數(shù)據(jù)寫操作的dao調(diào)用，要特別注意，比較優(yōu)雅的做法是，在刪除、修改、增加的數(shù)據(jù)時候，先預(yù)估一下大致的數(shù)據(jù)量，如果數(shù)據(jù)量不多，直接操作也不會有太大影響；如果數(shù)據(jù)量很大，建議劃分分若干組，小批量的進(jìn)行操作，這樣做有以下兩個原因：

• 大批量的數(shù)據(jù)寫操作，會造成大量數(shù)據(jù)鎖定狀態(tài)，引起其他業(yè)務(wù)操作的阻塞；

• 大批量的數(shù)據(jù)寫操作，會引起索引結(jié)構(gòu)的調(diào)整，消耗的時間更長；

小批量操作的好處，就是不會造成大量數(shù)據(jù)長時間鎖定而阻塞其他業(yè)務(wù)請求，另外也索引結(jié)構(gòu)的調(diào)整時間也會小一些，但這不代表把全部數(shù)據(jù)寫完所消耗的時間會更短，因?yàn)橛绊憯?shù)據(jù)庫讀寫的因素有很多，小批量數(shù)據(jù)寫操作更多考慮的是對業(yè)務(wù)整體的影響要更小。

優(yōu)雅調(diào)用遠(yuǎn)程服務(wù)接口

在《Springboot中如何優(yōu)雅的寫好controller層代碼》中，有小伙伴留言SpringCloud架構(gòu)的項(xiàng)目，也能按這樣的模式進(jìn)行嗎？其實(shí)完全沒有問題，因?yàn)镾pringCloud架構(gòu)的項(xiàng)目，本質(zhì)上是若干個springboot項(xiàng)目組成、彼此之間可以相互遠(yuǎn)程調(diào)用，所以只要是springboot項(xiàng)目都可以采用這樣的模式讓controller層的代碼清爽起來。

因此，如果是使用SpringCloud或Dubbo這樣分布式架構(gòu)的項(xiàng)目，在service層就會有一些遠(yuǎn)程調(diào)用，即調(diào)用另外一個項(xiàng)目的接口。這種情況，建議使用用try catch進(jìn)行異常捕獲處理，捕獲后有兩種選擇：如果這個遠(yuǎn)程調(diào)用失敗不影響當(dāng)前業(yè)務(wù)的繼續(xù)執(zhí)行，可以僅僅打印日志就行；如果這個遠(yuǎn)程調(diào)用失敗與當(dāng)前業(yè)務(wù)是強(qiáng)耦合關(guān)系，那就不僅要記錄異常日志，還要處理這個異常，處理的方式有很多，這舉幾個例子供作參考：

• 拋出自定義的運(yùn)行時異常，以便上層需要回滾就回回滾；

• 在catch里手動回滾其他數(shù)據(jù)操作；

• 記錄一下發(fā)生異常時的數(shù)據(jù)信息，讓程序繼續(xù)向下執(zhí)行，另外采用數(shù)據(jù)補(bǔ)償機(jī)制來補(bǔ)救；

• 在catch中實(shí)現(xiàn)重試機(jī)制（一般情況下，dubbo、springcloud中有重試機(jī)制，不需要自己單獨(dú)實(shí)現(xiàn)，這里主要是針對那些需要自己實(shí)現(xiàn)重試機(jī)制的情況）；

總之，異常處理的本質(zhì)是為保證程序順利執(zhí)行，記錄日志是為了發(fā)生異常時可以定位追蹤問題原因。不要為了記錄日志而去try catch，需要記錄的話，在關(guān)鍵位置記錄一下日志就可以了，滿屏都是try catch，太影響閱讀體驗(yàn)了。畢竟代碼最終是給虛擬機(jī)執(zhí)行的，但是首先是給人看的，閱讀性好，后續(xù)其他人在維護(hù)這段代碼的時候效率就高，那就可以少加班了，多爽。

同步方法與異步方法

一般情況下，程序里的方法調(diào)用都同步方法，即方法之間是順序執(zhí)行的。異步方法是指異步方法被調(diào)用的時候，不用等異步方法執(zhí)行完或有返回結(jié)果就可以繼續(xù)向下順序執(zhí)行其他方法。有的時候業(yè)務(wù)邏輯比較復(fù)雜，全部采用同步方法執(zhí)行，所需要消耗的時間就是所有順序執(zhí)行方法之和。一個比較有效的代化思路，就是可以把復(fù)雜業(yè)務(wù)邏輯中，對主線業(yè)務(wù)邏輯沒有影響的業(yè)務(wù)邏輯抽取成異步方法，這樣整個調(diào)用時間=同步方法的調(diào)用時間之和+異步方法中執(zhí)行最長時間；在性能上會有一定提高 。

控制方法長度

為什么要控制方法長度？最主要的原因是為了程序的可閱讀性和可維護(hù)性。相對比較短的方法，讀著就舒服，就讓人心情好，維護(hù)的時候能快速找到重點(diǎn)，改的時候效率就高。

怎么才能控制好方法長度？

建議了解一下設(shè)計模式六大原則中的單一職責(zé)；

有沒有什么好的標(biāo)準(zhǔn)呢？

給編程工具里安裝一個阿里編碼規(guī)約插件，如果我沒有記錯好像是80行，但是這個也不絕對，標(biāo)準(zhǔn)是死的，個別可以根據(jù)實(shí)際情況靈活變通，不要動不動就搞個幾百行、上千行的就行，如果給你一篇幾千字的文章，就一個段落，你會怎么想？

總之，大家不要相互挖坑，寫好代碼，早點(diǎn)下班，陪陪女朋友，陪陪家人、孩子，多香呀。

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級服務(wù)器適合批量采購，新人活動首月15元起，快前往官網(wǎng)查看詳情吧

當(dāng)前文章：Springboot中如何優(yōu)雅的寫好Service層代碼-創(chuàng)新互聯(lián)
轉(zhuǎn)載來源：http://chinadenli.net/article38/dgggpp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站維護(hù)、電子商務(wù)、自適應(yīng)網(wǎng)站、營銷型網(wǎng)站建設(shè)、網(wǎng)站制作、標(biāo)簽優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)