##背景介绍
在WEB程序设计中，通常我们会使用VO，DTO，Entity等等模型实现API接口 与数据库实体模型的分层隔离，提高系统的可维护性。
在本文中，将会介绍通过Java Record（）来实现DTO，看看它相比于我们普通的POJO来作为DTO，具备哪些优势。
##为什么要使用DTO？
有时候，我们的DTO或其他O 可能是完全等于数据库Entity的，我们可能会想为什么不直接复用我们的数据库Entity作为DTO作为RESTFul 接口中的资源对象呢？
确实，其实如果你能保证后续的需求变化也不会导致你的DTO 和 Entity 没有任何差异，那么确实可以直接使用Entity作为你的DTO返回给前端。但是有个几情况是需要我们不得不考虑的：
- 紧耦合：直接公开Entity将会导致 API 与数据库模型绑定得太紧密。 对数据库结构的任何更改都可能会强制更改 API，从而破坏向后兼容性并可能影响客户端。
- 安全风险：Entity 通常包含 API 使用者不应直接看到的字段。 暴露它们会增加无意中泄露数据的风险。
- 数据转换： API 可能需要以不同于底层数据库表示的格式呈现数据，例如计算字段和合并来自多个实体的数据。
- 过度获取：Entity通常会建模与其他实体的关系。 直接公开它们可能会导致返回的数据多于客户端实际需要的数据，从而影响性能。
那么显而易见，通过DTO我们可以很好的避免以上的问题。
- 解耦 ： API 与数据Entity 隔离，支持更多灵活性。
- 安全性：仅公开必要的数据，降低安全风险。
- 定制： 可以设计 DTO 来匹配 API 要求或特定视图。
- 性能： DTO 允许仅获取和传输客户端所需的数据。
## 使用JAVA Record 来实现DTO
Java Record 首次在 Java 14 中引入，非常适合定义 DTO。
它提供：
- 简洁的语法：可以消除通常与传统 DTO 类相关的样板代码。
- 不变性：默认情况下，记录是不可变的，确保跨层数据的完整性。
- 可读性：Record使 DTO 的意图更清晰。
---
下面我们来写个Demo 感受一下，假设有一个Book的Entity
首先我们来看一下常规的POJO实现DTO：
当然，这里我使用lombok的@data 来简化了setter和getter的代码，看起来还是不错的。但是别眨眼，让我们看看Java Record！
现在，使用 Java Record作为DTO
没错，代码写完了，就是这么简单。也不需要引入lombok 第三方库。
同时由于Java Record提供的 **不变性**，我们可以避免不可变的DTO由于意外修改状态而引发的bug，同时使得代码更容易推理和维护。**不可变性** 也使得对象在多线程环境中被共享时更加安全。
然后我们就可以把BookDTO 当作我们的响应模型返回给前端。
## 总结
本文介绍了使用Java Record来作为DTO的应用场景，通过使用 DTO 并利用 Java Record的简洁性，可以创建更安全、更可维护且简约的REST API。
希望通过这篇简短的文章可以抛砖引玉，让大家更多的了解Java世界一些新的更新，大家多多交流分享～