为什么需要DTO(数据传输对象)(转载)

本文探讨了DTO(数据传输对象)与实体模型的作用与区别,解释了为何在软件开发中使用DTO来隔离业务逻辑与展示层,从而实现解耦。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

DTO即数据传输对象。之前不明白有些框架中为什么要专门定义DTO来绑定表现层中的数据,为什么不能直接用实体模型呢,有了DTO同时还要维护DTO与Model之间的映射关系,多麻烦。

然后看了这篇文章中的讨论部分才恍然大悟。

摘两个比较有意义的段落。

表现层与应用层之间是通过数据传输对象(DTO)进行交互的,数据传输对象是没有行为的POCO对象,它 的目的只是为了对领域对象进行数据封装,实现层与层之间的数据传递。为何不能直接将领域对象用于 数据传递?因为领域对象更注重领域,而DTO更注重数据。不仅如此,由于“富领域模型”的特点,这样 做会直接将领域对象的行为暴露给表现层。

需要了解的是,数据传输对象DTO本身并不是业务对象。数据传输对象是根据UI的需求进行设计的,而不 是根据领域对象进行设计的。比如,Customer领域对象可能会包含一些诸如FirstName, LastName, Email, Address等信息。但如果UI上不打算显示Address的信息,那么CustomerDTO中也无需包含这个 Address的数据

实体模型变化的可能性比较的大!尤其是在一期 转到 二期, 二期转到三期
以及前期发现实体设计可能存在不合理的情况。

这个时候我们需要修改实体!

由于我们的实体在很多层次上都用了,那么每修改一次实体,可能其他很多地方都需要变更。

但是引入了DTO对象,这个变得不同了,实体的变更,我只需要变更实体与DTO的转换过程。

比如说,本来有Item与ItemDTO对象,下一个时候我发现Item对象中许多字段存在冗余,实体设计得不好,可能需要拆分!那么若无ItemDTO,上层逻辑直接依赖于Item实体的话,需要将依赖的地方都进行修改。

若有ItemDTO,上层 只依赖于 ItemDTO,而不依赖于Item实体,这样,我们只需要想办法修改 将ItemDTO与变更后的若干个实体进行正确转换。上层 不需要动任何代码 的说。

不过这样写,多了一个DTO与Pojo以及VO之间的转换,确实......代码要多很多,挺麻烦 的说。

简单来说Model面向业务,我们是通过业务来定义Model的。而DTO是面向界面UI,是通过UI的需求来定义的。通过DTO我们实现了表现层与Model之间的解耦,表现层不引用Model,如果开发过程中我们的模型改变了,而界面没变,我们就只需要改Model而不需要去改表现层中的东西。

SSM(Spring + Spring MVC + MyBatis)是一个常用的企业级Java Web应用架构,用于构建数据驱动的Web应用程序。如果你想要在SSM框架下新建一个Web项目,并实现文章的转载和转账功能,可以按照以下步骤操作: 1. **项目结构搭建**: - 创建一个新的Spring Boot项目,这是基于Maven或Gradle的。 - 分别配置Spring MVC作为控制器层、MyBatis作为持久层以及Spring Data JPA/Repository作为DAO层。 2. **数据库设计**: - 设计两个相关的表,比如`articles`表存储文章信息,`transfers`表处理转账记录。 - 需要有字段如文章ID、用户名、转账金额等。 3. **Controller实现**: - 定义Controller类,通过@RequestBody解析请求体中的数据。 - 转载功能:创建一个POST请求,接收文章ID,查询到原文章并复制相关数据保存至新的文章记录中。 ```java @PostMapping("/repost") public ResponseEntity<?> repost(@RequestBody Long articleId) { Article originalArticle = repository.findById(articleId).orElseThrow(); // 处理并保存新文章 } ``` - 转账功能:同样创建POST请求,处理用户转账的数据,验证合法性,然后更新`transfers`表。 ```java @PostMapping("/transfer") public ResponseEntity<?> transfer(@RequestBody TransferRequest request) { // 验证请求,查询账户余额等 boolean success = service.transfer(request); if (success) { return ResponseEntity.ok().build(); } else { return ResponseEntity.badRequest().build(); } } ``` 4. **Service与Repository**: - Service层处理业务逻辑,包括数据访问的封装和异常处理。 - Repository层负责具体的数据库交互,通过接口方法调用MyBatis的SQL。 5. **数据传输模型**: - 使用数据传输对象(DTO)或者Vo对象将数据库查询结果转换为便于前端使用的格式。 6. **安全性考虑**: - 对转账功能进行权限控制,例如需要登录用户才能操作转账。 - 数据传输过程中保护敏感信息,如使用HTTPS加密通信。 7. **测试**: 编写单元测试和集成测试,确保功能的正常工作。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值