首先明白springboot每層
model層
model層即數據庫實體層，也被稱為entity層，pojo層。 一般數據庫一張表對應一個實體類，類屬性同表字段一一對應。
Model層是數據層: TableName是對數據表實體的映射；
Criteria傳輸前台數據
DTO 傳輸類間數據
dao層
dao層即數據持久層，也被稱為mapper層。 dao層的作用為訪問數據庫，向數據庫發送sql語句，完成數據的增刪改查任務。
service層
service層即業務邏輯層。 service層的作用為完成功能設計。 service層調用dao層接口，接收dao層返回的數據，完成項目的基本功能設計。
controller層
controller層即控制層。 controller層的功能為請求和響應控制。 controller層負責前后端交互，接受前端請求，調用service層，接收service層返回的數據，最后返回具體的頁面和數據到客戶端
DTO即數據傳輸對象。
現狀
對於分布式系統，需要在不同系統之間傳遞與轉換域對象。因為我們不希望外部公開內部域對象，也不允許外部域對象滲入系統。傳統上，數據對象之間的映射通過手工編碼(getter/setter)的方式實現，或對象組裝器（或轉換器）來解決。我們可能會開發某種自定義映射框架來滿足我們的映射轉換需求，但這一切都顯得不夠靈巧。
之前不明白有些框架中為什么要專門定義DTO來綁定表現層中的數據，為什么不能直接用實體模型呢，有了DTO同時還要維護DTO與Model之間的映射關系，多麻煩
model層即數據庫實體層，也被稱為entity層，pojo層。
然后看了這篇文章中的討論部分才恍然大悟。
摘兩個比較有意義的段落。
表現層與應用層之間是通過數據傳輸對象（DTO）進行交互的，數據傳輸對象是沒有行為的POCO對象，它 的目的只是為了對領域對象進行數據封裝，實現層與層之間的數據傳遞。為何不能直接將領域對象用於 數據傳遞？因為領域對象更注重領域，而DTO更注重數據。不僅如此，由於“富領域模型”的特點，這樣 做會直接將領域對象的行為暴露給表現層。
需要了解的是，數據傳輸對象DTO本身並不是業務對象。數據傳輸對象是根據UI的需求進行設計的，而不 是根據領域對象進行設計的。比如，Customer領域對象可能會包含一些諸如FirstName, LastName, Email, Address等信息。但如果UI上不打算顯示Address的信息，那么CustomerDTO中也無需包含這個 Address的數據。
簡單來說Model面向業務，我們是通過業務來定義Model的。而DTO是面向界面UI，是通過UI的需求來定義的。通過DTO我們實現了表現層與Model之間的解耦，表現層不引用Model，如果開發過程中我們的模型改變了，而界面沒變，我們就只需要改Model而不需要去改表現層中的東西。
這篇文章主要來談論一下DTO使用的場合及其帶來的好處。首先要理解DTO是什么？
DTO就是數據傳輸對象(Data Transfer Object)的縮寫。 DTO模式，是指將數據封裝成普通的JavaBeans，在J2EE多個層次之間傳輸。 DTO類似信使，是同步系統中的Message。 該JavaBeans可以是一個數據模型Model。
在傳統的編程中，我們一般都是前台請求數據，發送到Webservice，然后WebService向數據庫發出請求，獲取數據，然后一層層返回；模型如下：
這種比較原始的請求方式帶來的缺點有很多，多次請求耗費一定的網絡資源，減慢效率。如果一次性返回整個實體類，還可能造成數據庫表結構的泄漏。
采用DTO模型之后，整個流程就不一樣了：
這樣帶來的好處有：
1.依據現有的類代碼，即可方便的構造出DTO對象，而無需重新進行分析。
2.減少請求次數，大大提高效率。
3.按需組織DTO對象，頁面需要的字段我才組織，不需要的我不組織，可以避免傳輸整個表的字段，一定程度上提高了安全性。
結合個人的開發經驗來談一下用法：
一般我們使用DTO類來繼承entity實體類，在DTO類里放一些業務字段，並提供get、set方法。當我們在業務邏輯層或者交互層用到一些數據庫中不存在的字段時，比如：我的一路順風汽車電商項目中，使用DTO對，offset，limit,order,sort,search,這些字段在數據庫是沒有的 。我們就需要在DTO類里放這些字段，這些字段的意義就相當於一些經處理過的數據庫字段，實質意義就是方便數據交互，提高效率。
更多關於DTO的優化，可以看下面這個博客文章
https://blog.csdn.net/yusimiao/article/details/90746891?utm_source=distribute.pc_relevant.none-task