简单来说，为什么我们在web应用程序中需要"bean到bean映射服务"（如Dozer）。
假设我正在开发一个web服务。
- 我收到一个XML请求
- 我从XML元素中获取值
- 对提取的值执行所需的操作
- 准备响应XML
- 将响应XML作为响应发送
为什么我应该再添加一个步骤，将XML元素映射到自己的自定义元素。
我无法说服自己，可能是因为我想不出更好的情况/理由。
如果可能的话，请举例说明。
它有助于减少表示（即XML模式）和业务逻辑之间的耦合。例如，在模式更改的情况下，您不必接触业务逻辑，只需接触对象之间的映射即可。
在简单的情况下，可能不值得增加复杂性。但是，如果这些对象在业务逻辑组件中被广泛使用，您应该考虑它。
作为一个快速的答案，您描述的案例并不是唯一的：）。
假设您正在使用一个内部库，该库提供一些POJO/实体/其他bean。您想要从内部表示中抽象（出于某种原因或其他原因），然后需要将这些bean映射到您的bean。它起作用：
- 对于ejb客户端或类似的东西
- 当您不想公开内部实体时（业务对象与演示对象）（请参见@Henry的回复）
- 您的bean不是从同一个父级继承的（由于任何原因，甚至是leacy，都不能继承），并且您希望将值从上转移到另一个
有很多（其他）原因：）
作为一个建议，请参阅orika以及这篇帖子：有java对象到对象映射的工具吗？
henry说的简短回答有助于减少您公开或使用的内容与核心数据模型之间的耦合。
这是建造六边形建筑的一种方式。您可以自由修改核心模型，而不会影响暴露的模型。在六边形架构中，它只用于暴露核心模型的一小部分相关部分。
这也是处理服务和模型版本控制的一种非常好的方式，因为多个版本可以映射到核心模型。
在使用XML服务时，我倾向于构建契约优先的应用程序，因此，我首先编写XMLSchema，然后生成Jaxbean，我真的不希望我的业务代码被JAxb注释污染。
如果您知道您的公开模型将始终相同，并且您的应用程序不属于前面提到的情况，那么您实际上不需要使用DTO。
最后，我建议使用像Selma这样的具有强编译时检查的框架，而不是Dozer或Orika，因为它们只在运行时评估映射，这是弱类型，对重构来说是明智的。