Why do we need a bean to bean mapper like dozer in a web application

Question

Simply put, why do we need a bean to bean mapping service (like Dozer) in a web application.

Suppose I am working on a web service.

• I get XML in the request.
• I am extracting values ​​from XML elements.
• Perform the required operation on the selected values.
• Prepare an XML response.
• Send XML response as response

Why should I add another step to display the XML elements for my own elements.

I cannot convince myself, perhaps because I cannot think of a better situation / reason.

Please provide an example if possible.

Answer 1

This helps reduce the link between presentation (i.e., XML schema) and business logic. For example, in the case of schema changes, you do not need to touch on business logic, just a mapping between objects.

In simple cases, this may not be worth the extra complexity. But if objects are widely used in a business logic component, you should consider it.

Answer 2

As a quick answer, the case you described is not the only one :).

Suppose you are working with an internal library that provides some POJO / entity / other beans. You want to abstract from the internal representation (by reason or anorth), then you want to match these bean with yours. He works:

• for ejb client , or something like this,
• if you don't want to expose internal objects (Business Object vs Presentation) (see @Henry answer)
• you have beans that does not inherit from the same parent (and cannot be for any reason, even leacy), and you want to change the tarnsfert value from one to another

There are many other reasons :)

For advice, see also orika and this post: any tool to map Java objects to objects?

Answer 3

The short answer is for me, as Henry said that it helps reduce the link between what you publish or consume and your main data model.

This is one way to build hexagonal architecture . You can freely change your kernel model without affecting the exposed model. In hexagonal architecture, it is used to display only a small, important part of the base model.

It is also a very efficient way to process services and model versions, as several versions can be mapped to the base model.

When working with XML services, I tend to create a contracted first application, so I write XMLSchema first and then create Jaxbeans, and I really don't want my business code to be contaminated with JAxb annotations.

If you know that your exposed model will always be the same, and your application will not fall into the previously mentioned cases, so you really do not need to use DTO.

Finally, I would recommend using a framework with strong compile-time checking, like Selma instead of Dozer or Orika, because they only evaluate the display at runtime, which is weak and typical for refactoring.