當(dāng)前位置:首頁 > 公眾號精選 > 架構(gòu)師社區(qū)
[導(dǎo)讀]今天我們要探討的問題是:Service層需要接口?

作者:架構(gòu)思維

來源:toutiao.com/i6882356844245975563

今天我們要探討的問題是:Service層需要接口?

現(xiàn)在結(jié)合我參與的項(xiàng)目以及閱讀的一些項(xiàng)目源碼來看。如果「項(xiàng)目中使用了像Spring這樣的依賴注入框架,那可以不用接口」!

先來說說為什么使用了依賴注入框架以后,可以不使用接口!

不需要接口的理由

我整理了支持Service層和Dao層需要加上接口的理由,總結(jié)下來就這么三個:

  • 可以在尚未實(shí)現(xiàn)具體Service邏輯的情況下編寫上層代碼,如Controller對Service的調(diào)用

  • Spring默認(rèn)是基于動態(tài)代理實(shí)現(xiàn)AOP的,動態(tài)代理需要接口

  • 可以對Service進(jìn)行多實(shí)現(xiàn)

實(shí)際上,這三個理由都站不住腳!

先說說第一個理由:「上層可以在下層邏輯沒有實(shí)現(xiàn)的情況下進(jìn)行編碼」!很典型的面向接口編程,對層與層之間進(jìn)行了解耦,看起來好像沒有問題。

這種開發(fā)方式適合不同模塊之間是由不同的人或項(xiàng)目組開發(fā)的,因?yàn)闇贤ǖ某杀颈容^大。同時避免由于項(xiàng)目組之間開發(fā)進(jìn)度的差異而相互影響。

不過讓我們回想一下,在一般項(xiàng)目開發(fā)里面,有多少項(xiàng)目組是按層來切分開發(fā)任務(wù)的呢?實(shí)際上,大部分的項(xiàng)目都是按照功能劃分的。即使是現(xiàn)在前后端分離的情況,單純的后端開發(fā)也是按照功能模塊進(jìn)行任務(wù)劃分,即一個人負(fù)責(zé)從Controller層到DAO層的完整邏輯處理。在這種情況下,每一層都先定義一個接口,再去實(shí)現(xiàn)邏輯,除了增加了開發(fā)人員的工作量(當(dāng)然,如果代碼量計(jì)入工作量的話,那開發(fā)人員應(yīng)該也不是太排斥接口的?。?,實(shí)際沒有任何用處。

如果開發(fā)人員想在下層邏輯沒有完成的情況下,先開發(fā)上層邏輯,可以先編寫下層類的空方法來先完成上層的邏輯。

這里推薦一個個人比較喜歡的開發(fā)流程,自上向下的編碼流程:

  • 先在Controller層編寫邏輯,遇到需要委托Service調(diào)用的地方,直接先寫出調(diào)用代碼。優(yōu)先完成Controller層的流程

  • 然后使用IDE的自動補(bǔ)全,對剛才調(diào)用下層的代碼生成對應(yīng)的類和方法,在里面添加TODO

  • 等所有的類和方法都補(bǔ)全了,再基于TODO,按照上面的流程去一個個的完善邏輯。

此方法可以使你對業(yè)務(wù)流程有比較好的理解。

對于第二個理由,就完全不成立了。Spring默認(rèn)是基于動態(tài)代理的,不過通過配置是可以使用CGLib來實(shí)現(xiàn)AOP。CGLib是不需要接口的。

最后一個理由是「可以對Service進(jìn)行多實(shí)現(xiàn)」。這個理由不充分,或者說沒有考慮場景。實(shí)際上在大多數(shù)情況下是不需要多實(shí)現(xiàn),或者說可以使用其它方式替代基于接口的多實(shí)現(xiàn)。

另外,對于很多使用了接口的項(xiàng)目,項(xiàng)目結(jié)構(gòu)也是有待商榷的!下面,我們結(jié)合項(xiàng)目結(jié)構(gòu)來說明。

項(xiàng)目結(jié)構(gòu)與接口實(shí)現(xiàn)

一般項(xiàng)目結(jié)構(gòu)都是按層來劃分的,如下所示:

  • Controller

  • Service

  • Dao

對于不需要多實(shí)現(xiàn)的情況,也就不需要接口了。上面的項(xiàng)目結(jié)構(gòu)即可滿足要求。

對于需要多實(shí)現(xiàn)的情況,無論是現(xiàn)在需要,還是后面需要。這種情況下,看起來好像是需要接口。此時的項(xiàng)目結(jié)構(gòu)看起來像這樣:

  • Controller
  • Service

    • ----接口在一個包中
    • impl ---實(shí)現(xiàn)在另一個包里
  • Dao
對于上面的結(jié)構(gòu),我們來考慮多實(shí)現(xiàn)的情況下,該怎么處理? 第一種方式,是在Service中新增一個包,在里面編寫新的邏輯,然后修改配置文件,將新實(shí)現(xiàn)作為注入對象。
  • Controller
  • Service

    • ---- 接口在一個包中
    • impl ---實(shí)現(xiàn)在另一個包里
    • impl2 ---新實(shí)現(xiàn)在另一個包里
  • Dao
第二種方式,是新增一個Service模塊,在里面編寫新的邏輯(注意這里的包和原來Service的包不能相同,或者包相同,但是類名不同,否則無法創(chuàng)建類。因?yàn)樵诩虞d時需要同時加載兩個Service模塊,如果包名和類名都相同,兩個模塊的類全限定名就是一樣的了?。缓笮薷呐渲梦募?,將新邏輯作為注入對象。
  • Controller
  • Service

    • ---- 接口在一個包中
    • impl ---實(shí)現(xiàn)在另一個包里
  • Service2

    • impl2 ---新實(shí)現(xiàn)在另一個包里
  • Dao
相對而言,實(shí)際第一種方式相對更簡單一點(diǎn),只需要關(guān)注包層面。而第二種方式需要關(guān)注模塊和包兩個層面。另外,實(shí)際這兩種方式都導(dǎo)致了項(xiàng)目中包含了不需要的邏輯代碼。因?yàn)槔线壿嫸紩淮蜻M(jìn)包里。 不過,從結(jié)構(gòu)上來看,實(shí)際方式二的結(jié)構(gòu)要比方式一的結(jié)構(gòu)更清晰,因?yàn)閺哪K上能區(qū)分邏輯。 那有沒有辦法來結(jié)合兩者的優(yōu)點(diǎn)呢?答案是肯定的,而且操作起來也不復(fù)雜! 首先將接口和實(shí)現(xiàn)獨(dú)立開,作為一個獨(dú)立的模塊:
  • Controller
  • Service --- 接口模塊
  • ServiceImpl

    • impl ---實(shí)現(xiàn)在另一個包里
  • ServiceImpl2

    • impl2 ---新實(shí)現(xiàn)在另一個包里
  • Dao
其次,調(diào)整打包配置,ServiceImpl和ServiceImpl2二選一。既然ServiceImpl和ServiceImpl2是二選一,那ServiceImpl和ServiceImpl2的包結(jié)構(gòu)就可以相同。包結(jié)構(gòu)相同了,那調(diào)整了依賴以后,依賴注入相關(guān)的配置就不需要調(diào)整了。調(diào)整后,項(xiàng)目結(jié)構(gòu)看起來像這樣:
  • Controller
  • Service --- 接口模塊
  • ServiceImpl

    • impl ---實(shí)現(xiàn)在另一個包
  • ServiceImpl2

    • impl ---新實(shí)現(xiàn)和老實(shí)現(xiàn)在相同的包中
  • Dao
現(xiàn)在,ServiceImpl和ServiceImpl2模塊中的包結(jié)構(gòu)、類名都是一樣的。那我們還需要接口模塊嗎? 假設(shè),我們把Service接口模塊去掉,結(jié)構(gòu)變成了如下所示:
  • Controller
  • Service1 --- 老實(shí)現(xiàn)
  • Service2 --- 新實(shí)現(xiàn)
  • Dao
單純的通過調(diào)整模塊依賴,是否能實(shí)現(xiàn)Service的多實(shí)現(xiàn)?答案顯而易見吧?

不使用接口的缺點(diǎn)

上面給出了不使用接口的理由。不過不使用接口并不是完全沒有缺點(diǎn)的,主要問題就是在進(jìn)行多實(shí)現(xiàn)的時候,沒有一個強(qiáng)接口規(guī)范。即不能通過實(shí)現(xiàn)接口,借助IDE快速生成框架代碼。對于沒有實(shí)現(xiàn)的接口,IDE也能給出錯誤提醒。 一個不太優(yōu)雅的解決是,將原來的模塊里的代碼拷貝一份到新模塊中,基于老代碼來實(shí)現(xiàn)新的邏輯。 所以,如果一個項(xiàng)目需要多實(shí)現(xiàn)、且多實(shí)現(xiàn)數(shù)量較多(不過一般項(xiàng)目不會有多個實(shí)現(xiàn)的),則推薦使用接口。否則不需要使用接口。

總結(jié)

本文針對「Service層是否需要接口」這個問題,指出需要接口的理由的問題。以及個人對這個問題的觀點(diǎn),希望對大家有一些幫助。


免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點(diǎn),不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!

本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫?dú)角獸公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術(shù)解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關(guān)鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運(yùn)行,同時企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風(fēng)險,如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機(jī) 衛(wèi)星通信

要點(diǎn): 有效應(yīng)對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實(shí)提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅(jiān)持高質(zhì)量發(fā)展策略,塑強(qiáng)核心競爭優(yōu)勢...

關(guān)鍵字: 通信 BSP 電信運(yùn)營商 數(shù)字經(jīng)濟(jì)

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術(shù)學(xué)會聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(shù)(集團(tuán))股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉