DTO（Data Transfer Object）中需要傳遞的數(shù)據(jù)并非固定，而是根據(jù)業(yè)務(wù)場景和接口需求來判斷的。核心原則是：只傳遞必要的數(shù)據(jù)，避免冗余或敏感信息。以下從具體場景和判斷方法兩方面詳細(xì)說明：

一、DTO傳遞數(shù)據(jù)的核心原則

• 按需傳遞：只包含接口所需的字段，不多不少。
  • 例如：創(chuàng)建用戶接口只需傳遞用戶名、密碼、郵箱，無需傳遞用戶ID（數(shù)據(jù)庫自增）或創(chuàng)建時間（系統(tǒng)自動生成）。
• 隔離數(shù)據(jù)：避免直接暴露數(shù)據(jù)庫表結(jié)構(gòu)（POJO/Entity）。
  • 例如：用戶表可能有password字段，但查詢用戶列表的響應(yīng)DTO不應(yīng)包含該字段（敏感信息）。
• 適配接口：同一實體在不同接口中可能需要不同的DTO。
  • 例如：用戶實體的創(chuàng)建接口需要password，但查詢接口不需要；詳情接口可能包含更多字段（如注冊時間），而列表接口只需要ID和用戶名。

二、不同類型DTO的傳參判斷（結(jié)合場景）

DTO通常分為請求DTO（RequestDTO） 和響應(yīng)DTO（ResponseDTO），兩者的設(shè)計邏輯不同：

1. 請求DTO（接收客戶端參數(shù)）

作用：定義客戶端需要傳遞給后端的參數(shù)，用于接口輸入。
判斷依據(jù)：后端接口處理業(yè)務(wù)時，必須依賴哪些參數(shù)？

• 必填字段：業(yè)務(wù)邏輯必須的參數(shù)（如創(chuàng)建訂單時的商品ID、數(shù)量）。
• 可選字段：非必須但能優(yōu)化功能的參數(shù)（如分頁查詢時的頁碼、每頁條數(shù)，默認(rèn)有值則可選）。
• 禁止傳遞：
  • 系統(tǒng)自動生成的字段（如ID、createTime）。
  • 后端可推導(dǎo)的字段（如當(dāng)前登錄用戶ID，應(yīng)從令牌中獲取，而非客戶端傳遞，避免篡改）。
  • 敏感字段（如用戶角色ID，若客戶端無需指定，則不允許傳遞）。

示例：
創(chuàng)建運營商的BillerCreateRequestDTO需要傳遞：

// 必須傳遞：業(yè)務(wù)需要的核心信息
private String billerCode; // 運營商編碼（業(yè)務(wù)唯一標(biāo)識）
private String name;       // 運營商名稱
private String contact;    // 聯(lián)系人（非必須，但業(yè)務(wù)可能需要）
private String phone;      // 聯(lián)系電話（非必須）
// 禁止傳遞：系統(tǒng)自動處理的字段
// private Long id;          // 數(shù)據(jù)庫自增，無需客戶端傳
// private Integer status;   // 默認(rèn)為"待審批"，后端固定賦值

2. 響應(yīng)DTO（返回給客戶端的數(shù)據(jù)）

作用：定義后端需要返回給客戶端的結(jié)果，用于接口輸出。
判斷依據(jù)：客戶端展示或后續(xù)處理需要哪些數(shù)據(jù)？

• 必須返回：客戶端必須展示的核心信息（如訂單詳情中的訂單號、金額、狀態(tài)）。
• 按需返回：根據(jù)接口粒度決定（詳情接口返回全量，列表接口返回精簡）。
• 禁止返回：
  • 敏感信息（如用戶密碼、加密密鑰）。
  • 客戶端無需關(guān)心的內(nèi)部字段（如數(shù)據(jù)庫版本號、中間表關(guān)聯(lián)ID）。
  • 過大或無用的字段（如長文本日志，客戶端用不到則不返回）。

示例：
運營商詳情的BillerResultDTO需要返回：

// 必須返回：客戶端展示的核心信息
private String billerCode; // 編碼
private String name;       // 名稱
private String contact;    // 聯(lián)系人
private String phone;      // 電話
private String statusDesc; // 狀態(tài)描述（如"正常"，而非數(shù)據(jù)庫存儲的1）
// 按需返回：輔助信息
private LocalDateTime createTime; // 創(chuàng)建時間（客戶端可能需要展示）
// 禁止返回：
// private String auditRemark; // 內(nèi)部審批備注，客戶端無需知道
// private Integer status;     // 數(shù)據(jù)庫存儲的狀態(tài)碼（應(yīng)轉(zhuǎn)換為描述文字）

三、如何精準(zhǔn)判斷DTO需要哪些字段？

• 從業(yè)務(wù)流程出發(fā)
  • 思考接口的目的：這個接口是用來做什么的？（創(chuàng)建/查詢/更新/刪除）
  • 例如：更新運營商接口（BillerUpdateRequestDTO）需要billerCode（定位要更新的對象）和需要修改的字段（如name、phone），無需傳遞未修改的字段。
• 參考前端需求
  • 和前端開發(fā)者確認(rèn)：他們需要哪些參數(shù)來調(diào)用接口？需要哪些返回值來展示頁面？
  • 例如：前端列表頁只展示運營商的編碼、名稱、狀態(tài)，則列表接口的響應(yīng)DTO只需這三個字段，無需返回詳細(xì)地址等信息。
• 考慮數(shù)據(jù)安全性
  • 敏感字段（密碼、身份證號）即使前端需要，也應(yīng)脫敏處理（如138****5678）。
  • 權(quán)限相關(guān)字段（如用戶角色）若客戶端無需展示，則不返回。
• 避免"一刀切"
  • 不要為了省事用一個DTO適配所有接口（如用POJO直接當(dāng)DTO）。
  • 例如：用戶實體有10個字段，登錄接口只需返回ID、用戶名，而個人中心接口需要返回ID、用戶名、頭像、生日等，應(yīng)分別定義UserLoginResponseDTO和UserProfileResponseDTO。

四、常見錯誤與最佳實踐

• 錯誤1：DTO包含POJO的所有字段，包括id、createTime等系統(tǒng)字段。
  • → 改進：只保留接口所需字段，刪除冗余。
• 錯誤2：響應(yīng)DTO返回數(shù)據(jù)庫原始字段（如狀態(tài)用1/2/3，而非"正常/禁用/待審批"）。
  • → 改進：在Service層轉(zhuǎn)換為客戶端易理解的枚舉或描述文字。
• 錯誤3：請求DTO允許傳遞本應(yīng)后端控制的字段（如status狀態(tài)字段，客戶端可能惡意篡改）。
  • → 改進：狀態(tài)由后端根據(jù)業(yè)務(wù)邏輯（如審批通過后自動更新），而非客戶端傳遞。
• 最佳實踐：
  • 用@NotBlank、@NotNull等注解標(biāo)記請求DTO的必填字段，配合@Valid做參數(shù)校驗。
  • 響應(yīng)DTO中對日期字段格式化（如@JsonFormat(pattern = "yyyy-MM-dd")），方便前端處理。
  • 復(fù)雜場景下，使用工具（如MapStruct）自動完成POJO與DTO的轉(zhuǎn)換，減少手動代碼。

總結(jié)

DTO傳遞的數(shù)據(jù)=業(yè)務(wù)必需+前端需要+安全合規(guī)的交集。判斷時需結(jié)合具體接口的用途、前后端協(xié)作需求和數(shù)據(jù)安全性，避免冗余和暴露敏感信息。核心思想是：DTO是為接口服務(wù)的，而非為數(shù)據(jù)庫表服務(wù)。

到此這篇關(guān)于在Spring項目中，DTO層的作用詳解的文章就介紹到這了,更多相關(guān)spring項目dto層內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論