是否使用 DTO？答案

【问题标题】：Use DTO or not?是否使用 DTO？
【发布时间】：2025-12-11 12:10:01
【问题描述】：

这似乎是一个非常简单的设计问题，但我很好奇你的意见。

我有一个 DAO 层，一个方法返回某事物的最大值和最小值。所以它返回两个整数值，但使用 int[] 和两个元素 int[0]=min_val 和 int[1]=max_val 作为返回类型对于方法调用者来说不是很清楚，因为他必须确切地知道哪个元素是第一个，哪个是第二个。

我应该在这里使用某种像这样的 DTO...

class RangeValuesDTO {
  private int min_val;

  private int max_val;
}

在这种简单的情况下，正确的模式是什么？

【问题讨论】：

我不会称之为 DTO。 DTO 的一个定义特征是它是一个用于传输通常驻留在另一个对象中的数据的对象——例如文件的打印输出。这里的对象不这样做；它只是一个完全正常的值对象（使用它似乎是个好主意！）。
我应该为 vo 对象创建额外的包...我的意思是... mypackages_structure.vo 还是应该在 dto 包中使用它们或...？我很好奇与 vos 合作时的良好做法
我建议按领域而不是技术标准打包类。因此，请将Range 类与生成它的 DAO 以及该 DAO 使用的实体类放在同一个包中。
嗯，也许吧。但是，当您为 vos 提供单独的包时，就像您通常为模型（实体）提供的那样，它是否更具可读性。然后您可以快速查看可用的 vo 类（如果某些新开发人员想要重用它们）。当然，你可以在任何地方上课。但是对我来说，当您为某种类（例如侦听器、异常、模型类、daos 等）设置单独的位置时，它是否更具可读性...
我认为这是一个品味问题。我自己发现这种组织基本上没用。我宁愿一起看到功能相关的类。做任何你认为最好的事情！

【解决方案1】：

你应该问问自己为什么需要某种模式。就企业模式而言，没有最佳实践之类的东西。正如@TechExchange 所建议的那样，将数据库中的数据结构包装在一个对象中以保持您的接口紧凑和稳定，这是一个有效的关注点。但正如@Tom Anderson 指出的那样，这应该被称为值对象，而不是 DTO。

请记住，对 DTO 模式的需求有一些历史原因（请参阅here），主要是在 EJB-3 之前的世界中。这些可能不再适用了。

DTO 可以帮助将更高层与直接访问数据层分开。然而，在一个简单的 CRUD 应用程序中，这可能会增加过多的间接性，从而增加不必要的重复和复杂性，从而增加维护性。您通常会得到与可能不会离开数据访问层的实体非常相似的 DTO。

DTO 在分布式系统中特别有用，它们会导致更粗粒度的接口并减少网络流量。

【讨论】：

【解决方案2】：

确实，您应该始终将数据包装在有意义且可重用的 DataStructures 中。

使用 DTO 将帮助您实现这一目标。

例如，将来如果你的 DAO 返回另一个 int 或 string 你会怎么做，如果你使用 DTO 解决方案很简单，将 int 或 string 添加到 DTO 并且不影响其他应用程序的层。

所以+1 DTO

【讨论】：