当我们谈论Java应用程序的开发时，数据传输对象被亲切地称为DTO，是许多讨论的主题。DTO诞生于Java世界中的EJB 2中有两个目的。

首先，规避EJB序列化问题；其次，它们隐式定义了一个组装阶段，在该阶段中，将要用于表示的所有数据在实际进入表示层之前都要进行封送处理。由于不再大规模使用EJB，是否还可以丢弃DTO？本文的目的是谈谈DTO的有用性并解决这个问题。

毕竟，在具有多个新主题的环境中（例如，云和微服务），该层甚至有意义吗？当涉及到良好的软件体系结构时，答案实际上是一致的：这取决于您希望实体与可视化层耦合的紧密程度。

考虑分层的基础架构，并将其自身分为三个相互连接的部分，我们拥有著名的MVC。

值得注意的是，该策略并非像Spring MVC和JSF这样的Web应用程序堆栈所独有。将数据暴露在具有JSON的宁静应用程序中，即使对典型数据不友好，JSON数据也可以可视化用户。

简要解释了MVC之后，我们将讨论使用DTO的优缺点。考虑到分层应用程序，DTO首先具有将模型与视图分离的目的。关于DTO问题的思考：

增加复杂性

有重复代码的可能性

添加新层会影响延迟层，即可能会导致性能损失。

在不需要丰富模型作为前提的简单系统中，不使用DTO可以为应用程序带来很多好处。有趣的一点是，许多序列化框架最终都迫使属性具有始终存在且必须公开的访问器，获取器和设置器方法，因此，在某些时候，这将影响应用程序的封装和安全性。

另一个选择是添加DTO层，这基本上保证了视图和模型的分离，如前所述。

它可以明确指出哪些字段将进入视图层。是的，在各种框架中都有一些注释，指示不会显示哪些字段。但是，如果您忘记写下来，则可能会意外导出关键字段，例如用户密码。

便于以面向对象的方式进行绘制。干净代码清楚地说明了面向对象的要点之一是OOP隐藏了数据以暴露行为，而封装则对此有所帮助。

便于更新数据库。在不影响客户的情况下，重构，迁移数据库通常是必不可少的。这种分离有助于优化和修改数据库，而不会影响可视化。

版本控制，向后兼容性是重要的一点，尤其是当您拥有一个供公众使用并有多个客户的API时，因此可以为每个版本都拥有一个DTO，并且无需担心就可以发展业务模型。

另一个好处是易于使用丰富模型，并且创建了子弹批准的API 。例如，在我的模型中，我可以使用money API。但是，在我的可视化层中，我导出为具有货币价值的简单对象来进行可视化。那是Java中正确的旧String。

CQRS。是的，命令查询职责隔离是否与写和读数据的职责分开有关，以及如何在没有DTO的情况下做到这一点？

通常，添加一层意味着去耦并简化维护，但要付出更多类和复杂性的代价，因为我们还必须考虑这些层之间的转换操作。例如，这就是存在MVC的原因，因此了解一切都基于影响和权衡或在给定应用程序或情况下的危害是非常重要的。

没有这些层是非常糟糕的，它可能导致出现Highlander模式（只能有一个），其中有一个班级要承担所有责任。同样，多余的层变成了洋葱图案，显影剂穿过每一层时都会在此处哭泣。

相关文章