DEV Community
·
Java提示：避免在服务层中使用DTO对象 #002
💡
原文约500字/词，阅读约需2分钟。
📝
内容提要
本文建议在服务层中避免使用DTO类的请求和响应对象，建议将其限制在Web层的控制器中。通过使用领域类处理服务方法的参数和返回值，可以保持层次责任和代码重用，确保服务逻辑在不同传输方式下的解耦。
🎯
关键要点
- 建议在服务层中避免使用DTO类的请求和响应对象，限制其在Web层的控制器中使用。
- Request和Response类应仅在Web层中定义，服务层应使用领域类处理参数和返回值。
- 使用领域类可以保持层次责任和代码重用，确保服务逻辑的解耦。
- 可以使用MapStruct或手动构建的Bean进行DTO与领域类之间的映射。
- DTO仅在控制器中使用，最多传递给映射层（DomainMapper和ResponseMapper）。
- 这种方法有助于保持层次责任和代码重用，适应不同的传输方式（如REST、消息队列等）。
- 通过创建特定的消息传递契约类，可以在不改变服务方法合同的情况下重用服务逻辑。
- 该方法遵循SOLID、Clean Code等原则，强调责任、组织和标准化。
❓
延伸问答
为什么在服务层中不建议使用DTO对象？
在服务层中不建议使用DTO对象是为了保持层次责任和代码重用，确保服务逻辑的解耦。
如何在服务层处理参数和返回值？
服务层应使用领域类处理参数和返回值，而不是使用DTO对象。
DTO对象应该在哪里使用？
DTO对象应仅在Web层的控制器中使用，最多传递给映射层。
如何实现DTO与领域类之间的映射？
可以使用MapStruct或手动构建的Bean进行DTO与领域类之间的映射。
这种方法对服务逻辑有什么影响？
这种方法有助于在不同传输方式下重用服务逻辑，保持服务方法合同不变。
这篇文章提到的设计原则有哪些？
文章提到的设计原则包括SOLID、Clean Code等，强调责任、组织和标准化。
➡️
