Bean-Mapping
For decoupling, you sometimes need to create separate objects (beans) for a different view. E.g. for an external service, you will use a transfer-object instead of the persistence entity so internal changes to the entity do not implicitly change or break the service.
Therefore you have the need to map similar objects what creates a copy. This also has the benefit that modifications to the copy have no side-effect on the original source object. However, to implement such mapping code by hand is very tedious and error-prone (if new properties are added to beans but not to mapping code):
public UserEto mapUser(UserEntity source) {
UserEto target = new UserEto();
target.setUsername(source.getUsername());
target.setEmail(source.getEmail());
...
return target;
}
Therefore we are using a BeanMapper
for this purpose that makes our lives a lot easier.
There are several bean mapping frameworks with different approaches.
For a devon4j-spring application we recommend Orika, follow Spring Bean-Mapping for an introduction to Orika and Dozer in a devon4j-spring context application.
Note
|
devon4j started with Dozer as framework for Spring applications and still supports it. However, we now recommend Orika (for new projects) as it is much faster (see Performance of Java Mapping Frameworks). |
For a Quarkus application we recommend Mapstruct, follow Quarkus Bean-Mapping for an introduction to Mapstruct in a quarkus context application.