Java 为什么在web应用程序中需要像dozer一样的bean-to-bean映射器

简单地说，为什么我们需要在web应用程序中使用“bean-to-bean映射服务”（比如Dozer）

假设我正在处理一个web服务

我收到一个XML请求

我从XML元素中获取值

对获取的值执行所需的操作

准备响应XML

将响应XML作为响应发送

为什么还要添加一个步骤将XML元素映射到自己的自定义元素

我无法说服自己，可能是因为我想不出更好的情况/理由

---

如果可能，请举例说明。

这有助于减少表示（即XML模式）和业务逻辑之间的耦合。例如，在模式更改的情况下，您不必触及业务逻辑，只需触及对象之间的映射

---

在简单的情况下，它可能不值得额外的复杂性。但是如果对象在业务逻辑组件中被广泛使用，你应该考虑它。

< P>作为一个快速回答，你所描述的情况并不是唯一的一个： 假设您正在使用一个内部库，该库提供一些POJO/entity/otherbean。您希望从内部表示中提取（出于某种原因或其他原因），然后希望将这些bean映射到您的bean。它的工作原理是：

• 对于ejb客户端，或者类似的东西
• 当您不想公开内部实体时（业务对象与表示对象）（参见@Henry的回复）
• 您的bean不是从同一个父级继承的（并且由于任何原因，甚至是leacy，都不能继承），您希望从一个到另一个的tarnsfert值

有很多（其他）原因：）

作为建议，请参见 这篇文章：

---

正如henry所说，这有助于减少您公开或使用的内容与您的核心数据模型之间的耦合

这是一种建设方式。您可以自由修改核心模型，而不会影响公开的模型。在六边形架构中，它仅用于暴露核心模型的一小部分相关部分

这也是处理服务和模型版本化的一种非常好的方法，因为多个版本可以映射到核心模型

在使用XML服务时，我倾向于构建契约优先的应用程序，因此，我首先编写XMLSchema，然后生成Jaxbeans，我真的不希望我的业务代码被JAxb注释污染

如果您知道您的公开模型总是相同的，并且您的应用程序不属于前面提到的情况，那么您确实不需要使用DTO

---

最后，我建议使用一个具有强编译时检查功能的框架，比如代替Dozer或Orika，因为它们只在运行时评估映射，这是弱类型的，对重构来说是明智的。

如果你看不到它的用途，你就不需要它。@FlorentBayle，它正在一个非常类似的项目中使用。这并不意味着你需要它。它可以用于历史原因，也可以用于不好的原因，来回答你不会面对的需求，。。。你必须问另一个项目为什么做出这个选择。