为什么我们在Web应用程序中需要像dozer这样的bean到bean映射器

Question

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

假设我正在开发网络服务。

1. 我在请求中收到了一个XML。
2. 我从XML元素中获取值。
3. 对获取的值执行所需的操作。
4. 准备响应XML。
5. 将响应XML作为响应发送

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

我无法说服自己，可能是因为我无法想到更好的情况/原因。

如果可能的话，请举例说明。

Answer 1

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

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

Answer 2

正如快速回答一样，您所描述的案例不是唯一的案例:)。

假设您正在使用提供某些POJO /实体/其他bean的内部库。你想从内部表示中抽象出来（出于某种原因或者是出于某种原因），然后你想将这些bean映射到你的。它有效：

• 适用于ejb客户端，或类似的内容，
• 当您不想公开内部实体（业务对象与演示文稿对象）时（请参阅@ Henry的回复）
• 你的豆子不能从同一个父母那里继承（并且因为任何原因，甚至是leacy）而且你想要将值从头开始转移到另一个 LI>

有很多（其他）原因：）

作为建议，另见orika 这篇文章： any tool for java object to object mapping?

Answer 3

亨利表示，它有助于减少您暴露或消费的内容与核心数据模型之间的耦合。

这是构建Hexagonal Architecture的单向方式。您可以自由修改核心模型，而不会影响暴露的模型。在六边形体系结构中，它仅用于暴露核心模型的一小部分相关部分。

由于可以将多个版本映射到核心模型，因此处理服务和模型版本化也是一种非常糟糕的方式。

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

如果您知道您的暴露模型将始终相同，并且您的应用程序不属于前面提到的案例，那么您真的不需要使用DTO。

最后，我建议使用具有强大编译时间检查的框架，如Selma而不是Dozer或Orika，因为它们仅在运行时评估映射，这是弱类型并且对重构很敏感。