技術(shù)可行，工程不宜。問題的核心不在于“是否能夠?qū)崿F(xiàn)”，而在于“復(fù)雜度應(yīng)該放在哪一層”。

一、為何有人選擇直接調(diào)用 Mapper

```java

@GetMapping("/user/{id}")

public User getUser(@PathVariable Long id) {

   return userMapper.selectById(id);

}

```

這種寫法的唯一吸引力在于減少層級(jí)：

無需編寫 Service 層

省略接口定義

避免實(shí)現(xiàn)類的創(chuàng)建

在以下場(chǎng)景中，這種做法短期內(nèi)可能不會(huì)引發(fā)明顯問題：

簡單的 CRUD 操作

個(gè)人項(xiàng)目或?qū)嶒?yàn)性代碼

演示原型或快速驗(yàn)證

因此，很多項(xiàng)目在初期往往采用這種方式。  

但問題在于：隨著業(yè)務(wù)發(fā)展，這種方式幾乎必然失控。

二、直接調(diào)用 Mapper 的必然問題

1. 業(yè)務(wù)膨脹時(shí)缺乏邏輯承載層

一旦需求涉及：

參數(shù)校驗(yàn)

權(quán)限判斷

狀態(tài)流轉(zhuǎn)

多表操作

Controller 將逐漸演變?yōu)檫@樣：

```java

User user = userMapper.selectById(id);

if (user == null) {

   throw new BizException("用戶不存在");

}

if (!user.isEnable()) {

   throw new BizException("用戶已禁用");

}

userMapper.updateStatus(id);

```

Controller 開始承擔(dān)本應(yīng)屬于 Service 的職責(zé)，而真正的業(yè)務(wù)邏輯層卻不存在了。

2. 事務(wù)無處安放

事務(wù)應(yīng)該放在哪里？

```java

@Transactional

@GetMapping("/user/update")

public void update() {

   // ...

}

```

盡管技術(shù)上可行，但這種設(shè)計(jì)非常糟糕：

Controller 承擔(dān)了事務(wù)語義，與表示層職責(zé)不符

接口層與業(yè)務(wù)邏輯強(qiáng)耦合

后期進(jìn)行服務(wù)拆分或重構(gòu)幾乎無法進(jìn)行

事務(wù)的自然歸屬應(yīng)當(dāng)是 Service 層。

3. Mapper 被“接口化”后復(fù)用價(jià)值歸零

一旦 Controller 直接依賴 Mapper：

其他 Service 若想復(fù)用同一數(shù)據(jù)操作，將不敢直接調(diào)用

定時(shí)任務(wù)或消息消費(fèi)者若需相同邏輯，調(diào)用層級(jí)將變得混亂

最終 Mapper 會(huì)退化為“僅特定接口使用的 DAO”，喪失通用性

三、何時(shí)可考慮直接調(diào)用 Mapper

僅有一種情況可考慮：完全沒有業(yè)務(wù)語義的純讀取接口。

例如：

后臺(tái)字典數(shù)據(jù)查詢

系統(tǒng)配置表讀取

只讀的基礎(chǔ)數(shù)據(jù)獲取

且必須滿足以下前提：

不涉及事務(wù)

無狀態(tài)判斷與流轉(zhuǎn)

未來無需擴(kuò)展或變更

即便如此，仍更推薦保留 Service 層，哪怕其中僅有一行代碼：

```java

public User getById(Long id) {

   return userMapper.selectById(id);

}

```

四、總結(jié)：Service 層的核心價(jià)值

Service 層不是為了“多寫一層代碼”，而是為了“隔離變化”。

它作為業(yè)務(wù)邏輯的容器，承擔(dān)以下關(guān)鍵職責(zé)：

封裝業(yè)務(wù)規(guī)則與流程

管理事務(wù)邊界

協(xié)調(diào)多個(gè) Mapper 或外部服務(wù)調(diào)用

提供可復(fù)用的邏輯單元

在項(xiàng)目初期或許感受不深，但隨著系統(tǒng)演進(jìn)，一個(gè)清晰分層的架構(gòu)能顯著提升代碼的可維護(hù)性、可測(cè)試性與可擴(kuò)展性。直接讓 Controller 調(diào)用 Mapper，雖可快速啟動(dòng)，卻為后續(xù)的架構(gòu)混亂埋下隱患。

建議始終遵循分層約定，將數(shù)據(jù)訪問職責(zé)交給 Mapper，將業(yè)務(wù)邏輯置于 Service，讓 Controller 專注于請(qǐng)求處理與響應(yīng)組裝。