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

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

不需要接口的理由

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

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

• Spring 默認是基于動態(tài)代理實現(xiàn) AOP 的，動態(tài)代理需要接口。

• 可以對 Service 進行多實現(xiàn)。

實際上，這三個理由都站不住腳!

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

這種開發(fā)方式適合不同模塊之間是由不同的人或項目組開發(fā)的，因為溝通的成本比較大。同時避免由于項目組之間開發(fā)進度的差異而相互影響。

不過讓我們回想一下，在一般項目開發(fā)里面，有多少項目組是按層來切分開發(fā)任務的呢?實際上，大部分的項目都是按照功能劃分的。

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

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

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

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

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

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

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

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

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

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

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

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

一般項目結(jié)構(gòu)都是按層來劃分的，如下所示：

• Controller

• Service

• Dao

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

對于需要多實現(xiàn)的情況，無論是現(xiàn)在需要，還是后面需要。這種情況下，看起來好像是需要接口。

此時的項目結(jié)構(gòu)看起來像這樣：

• Controller

• Service

----接口在一個包中

impl ---實現(xiàn)在另一個包里

• Dao

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

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

如下所示：

• Controller

• Service

---- 接口在一個包中

impl ---實現(xiàn)在另一個包里

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

• Dao

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

如下所示：

• Controller

• Service

---- 接口在一個包中

impl ---實現(xiàn)在另一個包里

• Service2

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

• Dao

相對而言，實際第一種方式相對更簡單一點，只需要關注包層面。而第二種方式需要關注模塊和包兩個層面。

另外，實際這兩種方式都導致了項目中包含了不需要的邏輯代碼。因為老邏輯都會被打進包里。

不過，從結(jié)構(gòu)上來看，實際方式二的結(jié)構(gòu)要比方式一的結(jié)構(gòu)更清晰，因為從模塊上能區(qū)分邏輯。

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

首先將接口和實現(xiàn)獨立開，作為一個獨立的模塊：

• Controller

• Service --- 接口模塊

• ServiceImpl

impl ---實現(xiàn)在另一個包里

• ServiceImpl2

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

• Dao

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

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

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

• Controller

• Service --- 接口模塊

• ServiceImpl

impl ---實現(xiàn)在另一個包

• ServiceImpl2

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

• Dao

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

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

• Controller

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

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

• Dao

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

不使用接口的缺點

上面給出了不使用接口的理由。不過不使用接口并不是完全沒有缺點的，主要問題就是在進行多實現(xiàn)的時候，沒有一個強接口規(guī)范。

即不能通過實現(xiàn)接口，借助 IDE 快速生成框架代碼。對于沒有實現(xiàn)的接口，IDE 也能給出錯誤提醒。

一個不太優(yōu)雅的解決是，將原來的模塊里的代碼拷貝一份到新模塊中，基于老代碼來實現(xiàn)新的邏輯。

所以，如果一個項目需要多實現(xiàn)、且多實現(xiàn)數(shù)量較多(不過一般項目不會有多個實現(xiàn)的)，則推薦使用接口。否則不需要使用接口。

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

當前標題：為什么Service層不需要接口
文章分享：http://jinyejixie.com/article10/jooogo.html

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

廣告

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