我想征求您对如何处理Spring Boot中的实体和DTO对象的看法。 我们在工作中有一个有趣的辩论。一个人始终将每个实体首先转换为DTO，然后对DTO进行更改，将其转换回实体，然后将其保存。从我的角度来看，这是一个不必要的操作。要执行保存，我将实体转换为DTO并再次返回，从而浪费了内存和资源。我并不是说它不需要，就像我必须以不同的方式表示实体一样，例如我需要从REST API返回结果时。在这种情况下，DTO（或实体预测）总是对我有意义。 我的方法总是尽可能快。这意味着我将实体加载到交易中（在弹簧启动持久性上下文中），请致电setter（可选，我也可以在存储库上拨打保存，但是即使推荐它，我也不会这样做），然后让更新发生。 我将对此进行一些性能测试，因为从我的角度来看，当我可以更简单地做到这一点时，始终将实体转换为DTO和返回的方法是浪费内存和CPU。

Question

VS

在我的批准中，我总是使用懒惰的提取，因为我不需要每个关联

inTransaction(
   var entity = repo.findById()
   entity.setValue()
   // optionally repo.save(entity)
) 

您对此有任何意见吗？

我尚未对此进行测试，但我希望第二种方法会更快

您的方法（直接修改交易中的实体）是更有效，更简单和清洁的。另一方面，您的同事的方法在大多数情况下是繁殖的，尽管在数据层之间进行严格的分离或使用不可变的DTO进行业务逻辑转换时有用。 <=>为什么？

1。实体生命周期和持久性上下文

在带有冬眠的春季启动中，在交易中检索时，将在

垂直上下文中进行管理。对实体所做的任何更改都将在交易结束时自动持续，而无需明确的

save()

，这要归功于

dirtychecking

.

。

Answer 1

entity → DTO → modify DTO → DTO → entity → save

）会导致不必要的对象创建和额外的处理，从而增加了CPU和内存使用范围。 2。懒惰与急切的提取

默认情况下，提取会导致加载不必要的数据，尤其是对于深度嵌套的对象，增加了查询执行时间。

• lazy fetching您的方法可确保仅加载必要的数据，从而提高效率。

  3。当DTO有意义

• 对于API响应

  ：DTOS有助于避免直接暴露实体结构。

  对于预测或转换
  ：如果需要重塑数据，则DTO是一个不错的选择。

对于外部系统集成：与外部API合作时，DTO提供了稳定的合同。

wo and，对于修改和持久的实体，不应是强制性的，除非：

：

• dto封装不应直接映射到实体的字段（例如，一些计算的字段）。

  更新过程涉及单独的验证或业务逻辑层，该层面不应直接与实体进行交互。

• 4。性能期望

您的方法应该更快地更快，因为它避免了不必要的对象转换和

repo.save()

。

在执行涉及多个实体的complex更新时，转换为DTO和背面的唯一场景可能是有用的。