Java Bean Mapping — Introduction, Part I
During the program execution, data can be converted to different data types or different objects. The reason behind this conversion can be data hiding or a business decision.
For instance, let’s consider we are working on an application and suppose the first step of this application is to register new users, one of the data points that we want to represent can be the age of the user. What kind of user information helps us to represent user age dynamically? If we can save the age statically, It would depend on the year that the that was submitted. However, when we save the birth date of the user, It can easily represent age with a date difference conversion. To do this, we need to convert this data.
This is why there should be many objects for each layer. First, we should have a request object that helps us to get data from users. After this operation, we should return an object in order to represent some information to the request sender. The information can either be updated with successful status or updated data. To achieve this, we need a response object. These object types are request and response called DTO (Data Transfer Object). The idea behind this abstraction is to give some specific intent to these objects.
DTO’s should not contain any business logic, they should be used only for transferring data between two applications.
In this article, I’ am going to show how can these objects convert each other in different ways.
The first part of the article consists of best practices and an introduction to the bean mapping. For the usage of mapping libraries, you may consider starting from the “Using Mapping Libraries” section.
For advanced programmers, the second part of the article is more useful!
Let’s define a model that consists of user information. Lombok was used in order to avoid complexity.
Lombok is a compile-time annotation that minimizes our code size.
To save these fields to our database, we need data that comes from real users. To do this, we should offer a new object for our client as below.
To convert a User Request object to User Entity, we need to initialize our entity with data that comes from our request object. How could we initialize our objects?
Construction!
Well, let’s add two constructions to our user entity.
As seen above, we have two different construction to initialize our user object. The company field will be optional because not all of our users might not work in a company.
However, these codes seem not well defined. At first glance, a programmer was able to not understand the intents of these two constructions. Besides, if we have lots of optional fields, it would be construction hell.
In fact, this situation has a name.
Telescoping Construction!
There are many anti-patterns that are used by many developers in order to save the day. However, programmers should avoid these kinds of patterns so that they are able to write clean and understandable code.
To find a solution, we need a better approach that comes from Effective Java.
The first item of the second chapter of the book is covering our needs.
“Consider static factory methods instead of constructions”
From this suggestion, we may consider creating static methods in order to define our intent. This pattern called Static Factory Method.
There could be two reasons for this approach.
First, we define our intention explicitly so that a programmer who uses our function, can understand our intent from the function’s names.
Second, we hide our construction and we could make some changes to data before initializing our user object using constructions. For instance, we may prefer to join the first name and last name as a full name.
After that, we could write our converter class with static factory methods. Thanks to well well-thought-out function names, the clients can easily use our functions.
And then we inject converter class to our service layer in order to convert User Request to the User entity.
Before moving onto mapper libraries, there is a better way to convert our object.
There is one more way for mapping, we can use the Java Bean Convention. This convention explicitly declared that we have to access private fields with special functions. These are called getters and setters. Using these special functions, we can convert our objects easily.
In this example, the User Request object is passed as a parameter to our converter function. Then fields that come from the request object are mapped to our entity using getter and setter functions. After that, this component could be injected into the service layer for converting operation.
In the next section, mapping libraries will be introduced and examples will be given about the usage.
