偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

CTO問:Service層真的需要接口嗎?

開發(fā) 前端 開發(fā)工具
前幾天刷到個問題:Service 層和 Dao 層真的有必要每個類都加上接口嗎?這個問題之前簡單回答了一波,給出的觀點是看情況!今天我們要探討的問題是:Service 層需要接口嗎?

前幾天刷到個問題:Service 層和 Dao 層真的有必要每個類都加上接口嗎?這個問題之前簡單回答了一波,給出的觀點是看情況!今天我們要探討的問題是:Service 層需要接口嗎?

[[353009]]

圖片來自 Pexels

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

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

不需要接口的理由

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

  • 可以在尚未實現(xiàn)具體 Service 邏輯的情況下編寫上層代碼,如 Controller 對 Service 的調(diào)用。
  • Spring 默認(rèn)是基于動態(tài)代理實現(xiàn) AOP 的,動態(tài)代理需要接口。
  • 可以對 Service 進(jìn)行多實現(xiàn)。

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

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

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

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

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

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

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

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

  • 先在 Controller 層編寫邏輯,遇到需要委托 Service 調(diào)用的地方,直接先寫出調(diào)用代碼。優(yōu)先完成 Controller 層的流程。
  • 然后使用 IDE 的自動補全,對剛才調(diào)用下層的代碼生成對應(yīng)的類和方法,在里面添加 TODO。
  • 等所有的類和方法都補全了,再基于 TODO,按照上面的流程去一個個的完善邏輯。

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

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

最后一個理由是可以對 Service 進(jìn)行多實現(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

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

另外,實際這兩種方式都導(dǎo)致了項目中包含了不需要的邏輯代碼。因為老邏輯都會被打進(jìn)包里。

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

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

首先將接口和實現(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)整了依賴以后,依賴注入相關(guān)的配置就不需要調(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)、類名都是一樣的。那我們還需要接口模塊嗎?

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

  • Controller
  • Service1 --- 老實現(xiàn)
  • Service2 --- 新實現(xiàn)
  • Dao

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

不使用接口的缺點

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

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

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

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

總結(jié)

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

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

編輯:陶家龍

出處:toutiao.com/i6882356844245975563

責(zé)任編輯:武曉燕 來源: 今日頭條
相關(guān)推薦

2024-05-07 08:43:30

Service分層設(shè)計接口

2020-03-04 10:13:55

Kubernetes容器開發(fā)

2020-04-17 14:25:22

Kubernetes應(yīng)用程序軟件開發(fā)

2017-08-24 08:18:00

2020-06-16 08:58:08

數(shù)據(jù)湖數(shù)據(jù)數(shù)據(jù)庫

2022-08-15 10:42:50

千兆網(wǎng)絡(luò)千兆光纖

2018-09-30 09:36:58

CTO代碼程序員

2011-01-04 09:31:04

jQueryWebApp

2021-06-01 10:49:22

線程池Java開發(fā)

2021-06-03 14:23:57

線程線程池JAVA

2011-10-09 14:37:40

打印機行情

2020-03-04 17:32:56

DevOpsDocker軟件

2018-07-12 11:48:31

微服務(wù)Service mes服務(wù)

2021-10-14 21:16:47

WebSocketCTO連接

2015-12-23 10:00:04

多種編程語言

2019-05-30 09:22:06

5G網(wǎng)絡(luò)互聯(lián)網(wǎng)

2023-09-22 07:52:16

HDMI 2.14K HDR游戲

2021-01-29 08:09:32

Service接口表現(xiàn)層

2014-11-27 15:38:57

互聯(lián)網(wǎng)隱私數(shù)據(jù)
點贊
收藏

51CTO技術(shù)棧公眾號