Skip to content

Latest commit

 

History

History
35 lines (22 loc) · 1.88 KB

guide-beanmapping.asciidoc

File metadata and controls

35 lines (22 loc) · 1.88 KB
Table of Contents

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.