為什么Service層不需要接口

這篇文章主要講解了“為什么Service層不需要接口”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“為什么Service層不需要接口”吧！

讓客戶(hù)滿(mǎn)意是我們工作的目標(biāo)，不斷超越客戶(hù)的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶(hù)，將通過(guò)不懈努力成為客戶(hù)在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名申請(qǐng)、網(wǎng)站空間、營(yíng)銷(xiāo)軟件、網(wǎng)站建設(shè)、馬村網(wǎng)站維護(hù)、網(wǎng)站推廣。

不需要接口的理由

我整理了支持 Service 層和 Dao 層需要加上接口的理由，總結(jié)下來(lái)就這么三個(gè)：

  • 可以在尚未實(shí)現(xiàn)具體 Service 邏輯的情況下編寫(xiě)上層代碼，如 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)題。

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

不過(guò)讓我們回想一下，在一般項(xiàng)目開(kāi)發(fā)里面，有多少項(xiàng)目組是按層來(lái)切分開(kāi)發(fā)任務(wù)的呢?實(shí)際上，大部分的項(xiàng)目都是按照功能劃分的。

即使是現(xiàn)在前后端分離的情況，單純的后端開(kāi)發(fā)也是按照功能模塊進(jìn)行任務(wù)劃分，即一個(gè)人負(fù)責(zé)從 Controller 層到 DAO 層的完整邏輯處理。

在這種情況下，每一層都先定義一個(gè)接口，再去實(shí)現(xiàn)邏輯，除了增加了開(kāi)發(fā)人員的工作量(當(dāng)然，如果代碼量計(jì)入工作量的話(huà)，那開(kāi)發(fā)人員應(yīng)該也不是太排斥接口的)，實(shí)際沒(méi)有任何用處。

如果開(kāi)發(fā)人員想在下層邏輯沒(méi)有完成的情況下，先開(kāi)發(fā)上層邏輯，可以先編寫(xiě)下層類(lèi)的空方法來(lái)先完成上層的邏輯。

這里推薦一個(gè)個(gè)人比較喜歡的開(kāi)發(fā)流程，自上向下的編碼流程：

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

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

  • 等所有的類(lèi)和方法都補(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)即可滿(mǎn)足要求。

對(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

對(duì)于上面的結(jié)構(gòu)，我們來(lái)考慮多實(shí)現(xiàn)的情況下，該怎么處理?

第一種方式，是在 Service 中新增一個(gè)包，在里面編寫(xiě)新的邏輯，然后修改配置文件，將新實(shí)現(xiàn)作為注入對(duì)象。

如下所示：

  • Controller

  • Service

---- 接口在一個(gè)包中

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

impl2 ---新實(shí)現(xiàn)在另一個(gè)包里

  • Dao

第二種方式，是新增一個(gè) Service 模塊，在里面編寫(xiě)新的邏輯(注意這里的包和原來(lái) Service  的包不能相同，或者包相同，但是類(lèi)名不同，否則無(wú)法創(chuàng)建類(lèi)。因?yàn)樵诩虞d時(shí)需要同時(shí)加載兩個(gè) Service  模塊，如果包名和類(lèi)名都相同，兩個(gè)模塊的類(lèi)全限定名就是一樣的了)，然后修改配置文件，將新邏輯作為注入對(duì)象。

如下所示：

  • Controller

  • Service

---- 接口在一個(gè)包中

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

  • Service2

impl2 ---新實(shí)現(xiàn)在另一個(gè)包里

  • Dao

相對(duì)而言，實(shí)際第一種方式相對(duì)更簡(jiǎn)單一點(diǎn)，只需要關(guān)注包層面。而第二種方式需要關(guān)注模塊和包兩個(gè)層面。

另外，實(shí)際這兩種方式都導(dǎo)致了項(xiàng)目中包含了不需要的邏輯代碼。因?yàn)槔线壿嫸紩?huì)被打進(jìn)包里。

不過(guò)，從結(jié)構(gòu)上來(lái)看，實(shí)際方式二的結(jié)構(gòu)要比方式一的結(jié)構(gòu)更清晰，因?yàn)閺哪K上能區(qū)分邏輯。

那有沒(méi)有辦法來(lái)結(jié)合兩者的優(yōu)點(diǎn)呢?答案是肯定的，而且操作起來(lái)也不復(fù)雜!

首先將接口和實(shí)現(xiàn)獨(dú)立開(kāi)，作為一個(gè)獨(dú)立的模塊：

  • Controller

  • Service --- 接口模塊

  • ServiceImpl

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

  • ServiceImpl2

impl2 ---新實(shí)現(xiàn)在另一個(gè)包里

  • Dao

其次，調(diào)整打包配置，ServiceImpl 和 ServiceImpl2 二選一。既然 ServiceImpl 和 ServiceImpl2 是二選一，那  ServiceImpl 和 ServiceImpl2 的包結(jié)構(gòu)就可以相同。

包結(jié)構(gòu)相同了，那調(diào)整了依賴(lài)以后，依賴(lài)注入相關(guān)的配置就不需要調(diào)整了。

調(diào)整后，項(xiàng)目結(jié)構(gòu)看起來(lái)像這樣：

  • Controller

  • Service --- 接口模塊

  • ServiceImpl

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

  • ServiceImpl2

impl ---新實(shí)現(xiàn)和老實(shí)現(xiàn)在相同的包中

  • Dao

現(xiàn)在，ServiceImpl 和 ServiceImpl2 模塊中的包結(jié)構(gòu)、類(lèi)名都是一樣的。那我們還需要接口模塊嗎?

假設(shè)，我們把 Service 接口模塊去掉，結(jié)構(gòu)變成了如下所示：

  • Controller

  • Service1 --- 老實(shí)現(xiàn)

  • Service2 --- 新實(shí)現(xiàn)

  • Dao

單純的通過(guò)調(diào)整模塊依賴(lài)，是否能實(shí)現(xiàn) Service 的多實(shí)現(xiàn)?答案顯而易見(jiàn)吧?

不使用接口的缺點(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)的)，則推薦使用接口。否則不需要使用接口。

感謝各位的閱讀，以上就是“為什么Service層不需要接口”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)為什么Service層不需要接口這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

當(dāng)前標(biāo)題：為什么Service層不需要接口
文章分享：http://muchs.cn/article10/jooogo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供手機(jī)網(wǎng)站建設(shè)、企業(yè)網(wǎng)站制作、ChatGPT、App設(shè)計(jì)、Google、電子商務(wù)

廣告

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

網(wǎng)站建設(shè)網(wǎng)站維護(hù)公司