當前位置: 妍妍網 > 碼農

分層設計:Service 層真的需要實作介面嗎?

2024-06-28碼農

架構師(JiaGouX)

我們都是架構師!
架構未來,你來不來?

前幾天看技術交流群的話題,又刷到了Service 層和 Dao 層真的有必要每個類都加上介面嗎?這個問題,之前簡單回答了一波,給出的觀點是看情況

現在結合我參與的計畫以及閱讀的一些計畫源碼來看,
如果計畫中使用了像 Spring 這樣的依賴註入框架,那可以不用介面!

先來說說為什麽使用了依賴註入框架以後,可以不使用介面。


不需要介面的理由

我整理了支持 Service 層和 Dao 層需要加上介面的理由,總結下來就這麽三個:

  • 可以在尚未實作具體 Service 邏輯的情況下編寫上層程式碼,如 Controller 對 Service 的呼叫

  • Spring 預設是基於動態代理實作 AOP 的,動態代理需要介面

  • 可以對 Service 進行多實作

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

    先說說第一個理由:「上層可以在下層邏輯沒有實作的情況下進行編碼」!很典型的面向介面編程,對層與層之間進行了解耦,看起來好像沒有問題。

    這種開發方式適合不同模組之間是由不同的人或計畫組開發的,因為溝通的成本比較大。同時避免由於計畫組之間開發進度的差異而相互影響。

    不過讓我們回想一下,在一般計畫開發裏面,有多少計畫組是按層來切分開發任務的呢?實際上,大部份的計畫都是按照功能劃分的。即使是現在前後端分離的情況,單純的後端開發也是按照功能模組進行任務劃分,即一個人負責從 Controller 層到 DAO 層的完整邏輯處理。在這種情況下,每一層都先定義一個介面,再去實作邏輯,除了增加了開發人員的工作量(當然,如果程式碼量計入工作量的話,那開發人員應該也不是太排斥介面的!),實際沒有任何用處。

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

    這裏推薦一個個人比較喜歡的開發流程,自上向下的編碼流程:

  • 先在 Controller 層編寫邏輯,遇到需要委托 Service 呼叫的地方,直接先寫出呼叫程式碼。

  • 優先完成 Controller 層的流程

  • 然後使用 IDE 的自動補全,對剛才呼叫下層的程式碼生成對應的類和方法,在裏面添加 TODO

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

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

  • 對於第二個理由,就完全不成立了。Spring 預設是基於動態代理的,不過透過配置是可以使用 CGLib 來實作 AOP。CGLib 是不需要介面的。

    最後一個理由是 可以對 Service 進行多實作 。這個理由不充分,或者說沒有考慮場景。實際上在大多數情況下是不需要多實作,或者說可以使用其它方式替代基於介面的多實作。

    另外,對於很多使用了介面的計畫,計畫結構也是有待商榷的!下面,我們結合計畫結構來說明。


    計畫結構與介面實作

    一般計畫結構都是按層來劃分的,如下所示:

  • Service

  • Dao

  • 對於不需要多實作的情況,也就不需要介面了。上面的計畫結構即可滿足要求。

    對於需要多實作的情況,無論是現在需要,還是後面需要。這種情況下,看起來好像是需要介面。此時的計畫結構看起來像這樣:

  • Service

  • 介面在一個包中

  • impl — 實作在另一個包裏

  • Dao

  • 對於上面的結構,我們來考慮多實作的情況下,該怎麽處理?

    第一種方式, 是在 Service 中新增一個包,在裏面編寫新的邏輯,然後修改配置檔,將新實作作為註入物件。

  • Service

  • —- 介面在一個包中

  • impl —實作在另一個包裏

  • impl2 —新實作在另一個包裏

  • Dao

  • 第二種方式, 是新增一個 Service 模組,在裏面編寫新的邏輯(註意這裏的包和原來 Service 的包不能相同,或者包相同,但是類名不同,否則無法建立類。因為在載入時需要同時載入兩個 Service 模組,如果包名和類名都相同,兩個模組的類全限定名就是一樣的了!),然後修改配置檔,將新邏輯作為註入物件。

  • Service

  • —- 介面在一個包中

  • impl —實作在另一個包裏

  • Service2

  • impl2 —新實作在另一個包裏

  • Dao

  • 相對而言,實際第一種方式相對更簡單一點 ,只需要關註包層面。而第二種方式需要關註模組和包兩個層面。另外,實際這兩種方式都導致了計畫中包含了不需要的邏輯程式碼。因為老邏輯都會被打進包裏。

    不過, 從結構上來看,實際方式二的結構要比方式一的結構更清晰,因為從模組上能區分邏輯。

    那有沒有辦法來結合兩者的優點呢?答案是肯定的,而且操作起來也不復雜!

    首先將介面和實作獨立開,作為一個獨立的模組:

  • Service — 介面模組

  • ServiceImpl

  • impl —實作在另一個包裏

  • ServiceImpl2

  • impl2 —新實作在另一個包裏

  • Dao

  • 其次,調整打包配置,ServiceImpl 和 ServiceImpl2 二選一。既然 ServiceImpl 和 ServiceImpl2 是二選一,那 ServiceImpl 和ServiceImpl2 的包結構就可以相同。包結構相同了,那調整了依賴以後,依賴註入相關的配置就不需要調整了。調整後,計畫結構看起來像這樣:

  • Service — 介面模組

  • ServiceImpl

  • impl —實作在另一個包

  • ServiceImpl2

  • impl —新實作和老實作在相同的包中

  • Dao

  • 現在,ServiceImpl 和 ServiceImpl2 模組中的包結構、類名都是一樣的。那我們還需要介面模組嗎?

    假設,我們把Service介面模組去掉,結構變成了如下所示:

  • Service1 — 老實作

  • Service2 — 新實作

  • Dao

  • 單純的透過調整模組依賴,是否能實作 Service 的多實作?答案顯而易見吧?


    不使用介面的缺點

    上面給出了不使用介面的理由。不過不使用介面並不是完全沒有缺點的,主要問題就是在進行多實作的時候,沒有一個強介面規範。即不能透過實作介面,借助 IDE 快速生成框架程式碼。對於沒有實作的介面,IDE 也能給出錯誤提醒。

    一個不太優雅的解決是,將原來的模組裏的程式碼拷貝一份到新模組中,基於老程式碼來實作新的邏輯。

    所以,如果一個計畫需要多實作、且多實作數量較多(不過一般計畫不會有多個實作的),則推薦使用介面。否則不需要使用介面。

    本文針對「Service 層是否需要介面」這個問題,指出需要介面的理由的問題。以及個人對這個問題的觀點,希望在評論區寫出自己的理解 !

    如喜歡本文,請點選右上角,把文章分享到朋友圈
    如有想了解學習的技術點,請留言給若飛安排分享

    因公眾號更改推播規則,請點「在看」並加「星標」 第一時間獲取精彩技術分享

    ·END·

    相關閱讀:

    作者:一頁清

    來源:https://www.toutiao.com/article/6882356844245975563/

    版權申明:內容來源網路,僅供學習研究,版權歸原創者所有。如有侵權煩請告知,我們會立即刪除並表示歉意。謝謝!

    架構師

    我們都是架構師!

    關註 架構師(JiaGouX),添加「星標」

    獲取每天技術幹貨,一起成為牛逼架構師

    技術群請 加若飛: 1321113940 進架構師群

    投稿、合作、版權等信箱: [email protected]