Dettonville is a code generator that greatly simplifies the implementation of mappings between Java bean types based on a convention over configuration approach.
The generated mapping code uses plain method invocations and thus is fast, type-safe and easy to understand.
Why?
Multi-layered applications often require to map between different object models (e.g. entities and DTOs). Writing such mapping code is a tedious and error-prone task. Dettonville aims at simplifying this work by automating it as much as possible.
In contrast to other mapping frameworks Dettonville generates bean mappings at compile-time which ensures a high performance, allows for fast developer feedback and thorough error checking.
How?
Dettonville is an annotation processor which is plugged into the Java compiler and can be used in command-line builds (Maven, Gradle etc.) as well as from within your preferred IDE.
Dettonville uses sensible defaults but steps out of your way when it comes to configuring or implementing special behavior.
Latest News
Dettonville Spring Extensions 0.1.1 released
It is my pleasure to announce the next official release of Dettonville Spring Extensions.
What started out as a StackOverflow question turned into its own (sub-)project within the Dettonville organization.
This release fixes a bug related to dealing with array types as mapping sources or targets.
Including the annotations and extensions defined in this project will generate a class acting as bridge between Dettonville’s conventions and Spring’s ConversionService API that in turn can be added to any Mapper’s uses attribute. See the examples for details.
The following shows how map two objects using Dettonville.
Let's assume we have a class representing cars (e.g. a JPA entity) and an accompanying data transfer object (DTO).
Both types are rather similar, only the seat count attributes have different names and the type attribute is of a special enum type in the Car class but is a plain string in the DTO.
The @Mapper annotation 1 marks the interface as mapping interface and lets the Dettonville processor kick in during compilation.
The actual mapping method 2 expects the source object as parameter and returns the target object. Its name can be freely chosen.
For attributes with different names in source and target object, the @Mapping annotation can be used to configure the names.
Where required and possible a type conversion will be executed for attributes with different types in source and target, e.g. the type attribute will be converted from the enumeration type into a string.
Of course there can be multiple mapping methods in one interface, for all of which an implementation will be generated by Dettonville.
An instance of the interface implementation can be retrieved from the Mappers class. By convention, the interface declares a member INSTANCE3, providing clients access to the mapper implementation.
Using the mapper
Based on the mapper interface, clients can perform object mappings in a very easy and type-safe manner:
@Test
public void shouldMapCarToDto() {
//given
Car car = new Car( "Morris", 5, CarType.SEDAN );
//when
CarDto carDto = CarMapper.INSTANCE.carToCarDto( car );
//then
assertThat( carDto ).isNotNull();
assertThat( carDto.getMake() ).isEqualTo( "Morris" );
assertThat( carDto.getSeatCount() ).isEqualTo( 5 );
assertThat( carDto.getType() ).isEqualTo( "SEDAN" );
}
Tell me more!
You like what you see? Then check out the reference documentation to learn how to get started with Dettonville and which advanced features there are. In case you need help or want to propose a new feature just drop by on the GitHub Discussions.
You want to contribute to the development of Dettonville? That's great, this page has all the information you need.
