CTO說(shuō):Service層的接口是不是多此一舉
來(lái)源:toutiao.com/i6882356844245975563
今天我們要探討的問(wèn)題是:Service層需要接口?
現(xiàn)在結(jié)合我參與的項(xiàng)目以及閱讀的一些項(xiàng)目源碼來(lái)看。如果「項(xiàng)目中使用了像Spring這樣的依賴注入框架,那可以不用接口」!
先來(lái)說(shuō)說(shuō)為什么使用了依賴注入框架以后,可以不使用接口!
不需要接口的理由
我整理了支持Service層和Dao層需要加上接口的理由,總結(jié)下來(lái)就這么三個(gè):
-
可以在尚未實(shí)現(xiàn)具體Service邏輯的情況下編寫上層代碼,如Controller對(duì)Service的調(diào)用
-
Spring默認(rèn)是基于動(dòng)態(tài)代理實(shí)現(xiàn)AOP的,動(dòng)態(tài)代理需要接口
-
可以對(duì)Service進(jìn)行多實(shí)現(xiàn)
實(shí)際上,這三個(gè)理由都站不住腳!
先說(shuō)說(shuō)第一個(gè)理由:「上層可以在下層邏輯沒(méi)有實(shí)現(xiàn)的情況下進(jìn)行編碼」!很典型的面向接口編程,對(duì)層與層之間進(jìn)行了解耦,看起來(lái)好像沒(méi)有問(wèn)題。
這種開發(fā)方式適合不同模塊之間是由不同的人或項(xiàng)目組開發(fā)的,因?yàn)闇贤ǖ某杀颈容^大。同時(shí)避免由于項(xiàng)目組之間開發(fā)進(jìn)度的差異而相互影響。
不過(guò)讓我們回想一下,在一般項(xiàng)目開發(fā)里面,有多少項(xiàng)目組是按層來(lái)切分開發(fā)任務(wù)的呢?實(shí)際上,大部分的項(xiàng)目都是按照功能劃分的。即使是現(xiàn)在前后端分離的情況,單純的后端開發(fā)也是按照功能模塊進(jìn)行任務(wù)劃分,即一個(gè)人負(fù)責(zé)從Controller層到DAO層的完整邏輯處理。在這種情況下,每一層都先定義一個(gè)接口,再去實(shí)現(xiàn)邏輯,除了增加了開發(fā)人員的工作量(當(dāng)然,如果代碼量計(jì)入工作量的話,那開發(fā)人員應(yīng)該也不是太排斥接口的?。?,實(shí)際沒(méi)有任何用處。
如果開發(fā)人員想在下層邏輯沒(méi)有完成的情況下,先開發(fā)上層邏輯,可以先編寫下層類的空方法來(lái)先完成上層的邏輯。
這里推薦一個(gè)個(gè)人比較喜歡的開發(fā)流程,自上向下的編碼流程:
-
先在Controller層編寫邏輯,遇到需要委托Service調(diào)用的地方,直接先寫出調(diào)用代碼。優(yōu)先完成Controller層的流程
-
然后使用IDE的自動(dòng)補(bǔ)全,對(duì)剛才調(diào)用下層的代碼生成對(duì)應(yīng)的類和方法,在里面添加TODO
-
等所有的類和方法都補(bǔ)全了,再基于TODO,按照上面的流程去一個(gè)個(gè)的完善邏輯。
此方法可以使你對(duì)業(yè)務(wù)流程有比較好的理解。
對(duì)于第二個(gè)理由,就完全不成立了。Spring默認(rèn)是基于動(dòng)態(tài)代理的,不過(guò)通過(guò)配置是可以使用CGLib來(lái)實(shí)現(xiàn)AOP。CGLib是不需要接口的。
最后一個(gè)理由是「可以對(duì)Service進(jìn)行多實(shí)現(xiàn)」。這個(gè)理由不充分,或者說(shuō)沒(méi)有考慮場(chǎng)景。實(shí)際上在大多數(shù)情況下是不需要多實(shí)現(xiàn),或者說(shuō)可以使用其它方式替代基于接口的多實(shí)現(xiàn)。
另外,對(duì)于很多使用了接口的項(xiàng)目,項(xiàng)目結(jié)構(gòu)也是有待商榷的!下面,我們結(jié)合項(xiàng)目結(jié)構(gòu)來(lái)說(shuō)明。
項(xiàng)目結(jié)構(gòu)與接口實(shí)現(xiàn)
一般項(xiàng)目結(jié)構(gòu)都是按層來(lái)劃分的,如下所示:
-
Controller
-
Service
-
Dao
對(duì)于不需要多實(shí)現(xiàn)的情況,也就不需要接口了。上面的項(xiàng)目結(jié)構(gòu)即可滿足要求。
對(duì)于需要多實(shí)現(xiàn)的情況,無(wú)論是現(xiàn)在需要,還是后面需要。這種情況下,看起來(lái)好像是需要接口。此時(shí)的項(xiàng)目結(jié)構(gòu)看起來(lái)像這樣:
- Controller
- Service
-
- ----接口在一個(gè)包中
- impl ---實(shí)現(xiàn)在另一個(gè)包里
- Dao
- Controller
- Service
-
- ---- 接口在一個(gè)包中
- impl ---實(shí)現(xiàn)在另一個(gè)包里
- impl2 ---新實(shí)現(xiàn)在另一個(gè)包里
- Dao
- Controller
- Service
-
- ---- 接口在一個(gè)包中
- impl ---實(shí)現(xiàn)在另一個(gè)包里
- Service2
-
- impl2 ---新實(shí)現(xiàn)在另一個(gè)包里
- Dao
- Controller
- Service --- 接口模塊
- ServiceImpl
-
- impl ---實(shí)現(xiàn)在另一個(gè)包里
- ServiceImpl2
-
- impl2 ---新實(shí)現(xiàn)在另一個(gè)包里
- Dao
- Controller
- Service --- 接口模塊
- ServiceImpl
-
- impl ---實(shí)現(xiàn)在另一個(gè)包
- ServiceImpl2
-
- impl ---新實(shí)現(xiàn)和老實(shí)現(xiàn)在相同的包中
- Dao
- Controller
- Service1 --- 老實(shí)現(xiàn)
- Service2 --- 新實(shí)現(xiàn)
- Dao
不使用接口的缺點(diǎn)
上面給出了不使用接口的理由。不過(guò)不使用接口并不是完全沒(méi)有缺點(diǎn)的,主要問(wèn)題就是在進(jìn)行多實(shí)現(xiàn)的時(shí)候,沒(méi)有一個(gè)強(qiáng)接口規(guī)范。即不能通過(guò)實(shí)現(xiàn)接口,借助IDE快速生成框架代碼。對(duì)于沒(méi)有實(shí)現(xiàn)的接口,IDE也能給出錯(cuò)誤提醒。 一個(gè)不太優(yōu)雅的解決是,將原來(lái)的模塊里的代碼拷貝一份到新模塊中,基于老代碼來(lái)實(shí)現(xiàn)新的邏輯。 所以,如果一個(gè)項(xiàng)目需要多實(shí)現(xiàn)、且多實(shí)現(xiàn)數(shù)量較多(不過(guò)一般項(xiàng)目不會(huì)有多個(gè)實(shí)現(xiàn)的),則推薦使用接口。否則不需要使用接口。總結(jié)
本文針對(duì)「Service層是否需要接口」這個(gè)問(wèn)題,指出需要接口的理由的問(wèn)題。以及個(gè)人對(duì)這個(gè)問(wèn)題的觀點(diǎn),希望對(duì)大家有一些幫助。
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問(wèn)題,請(qǐng)聯(lián)系我們,謝謝!