Enterprise application architecture patterns play a vital role in dealing with a lot of complex data. These are the standardized solution for large system's common problems. Enterprise application allows us to manipulate, display and store massive amounts of data. When we work on enterprise applications, we should think about avoiding tight coupling and ensuring data integrity/security before working on it.
DTO stands for Data Transfer Object, which is a design pattern. It is one of the EPA patterns which we call when we need to use such objects that encapsulate and aggregate data for transfer. A DTO is similar to a data structure, but like a data structure, it doesn't contain any business logic. It contains mechanisms of serialization and de-serialization. In DTO, we can store data from a single source or from multiple resources. We can either store complete data or can store a small amount of data from a source.
If we implemented DTOs in the code, it means that data transportation is done between the systems. The DTO is mainly used for reducing the number of expensive remote calls. In order to convert data between the DTO and any entity objects, the assembler object was defined, but now we are using mappers for converting data.
Implementing Data Transfer Object
In order to implement DTO, let's create a Spring Boot application that exposes REST API. By using that Spring Boot application, we can retrieve the user locations from an H2 database. For implementing that application, we should have knowledge of how to integrate the H2 database with Spring Boot. To learn more about the H2 database, click here.
The Spring Initializr is one of the easiest ways to work with a very first Spring Boot application.
The Spring Boot CLI is an alternative of spring initializr to develop bootstrap application.
In case if we already have Spring Boot or maven application, we have to add the following dependency in the pom.xml file.
We need to add the following line of code, if we use Gradle:
Let's implement a demo application by starting with designing the User model:
In the above class, we create an Entity with some user information such as username, name, pass and email and also create mant-to-one relationship between user entity and Location entity. The Location Entity is given below:
In order to perform basic CRUD operations, we use the trusty CrudRepository provided by Spring Boot:
If you don't have knowledge about how we use these repositories, click here.
Now, we need to create a controller for handling a GET request and returning a list of user's locations. The User and Location objects(retrieved from the database) will also contain some additional information such as the username and the password. We only print the required and necessary data from these objects, but the additional data still will be there.
As we already told you before that by using DTO, we can share either required data or complete data from the source. Now, we create DTO for transferring required data, and we transfer data of both objects together by aggregating them.
Now, our object contains all the information which we want to show to the user. In order to map both the objects into a UserLocationDTO, we need some mapping tools such as ModelMapper and MapStruct. Both these tools play a vital role in mapping objects into a single DTO.
We can also perform conversion manually, and for that, we need to implement a service that will call UserRepository and return the DTOs.
Let's implement the service class for mapping the objects into a single DTO.
After getting a list of Users, we can convert them into UserLocationDTO objects directly with their location information.
Note: When the endpoint is called by a user or another service that parses the result, it returns a @ResponseBody that will contain a list of UserLocationDTO.
Now, we add some dummy data of Location and User in the Hibernate database for testing purposes:
Now, we use the Postman to hit the endpoint and test whether our api endpoint is working or not.