Introduction to Spring Boot and JDBCTemplate: Introduction to Rest

REST has quickly become the de-facto standard for building web services on the web because they’re easy to build and easy to consume. In the second part of this series about Spring Boot with JDBCTemplate, we’ll explore how to create a Rest application.

We talked about the database integration in the first part, and we showed a test with H2. The next step is to expose this model as a rest resource, and every time a team needs to do it, the first question is about the DTO.

Data Transfer Objects, known affectionately as DTOs, are the subject of many discussions about developing Java applications, especially rest and MVC applications.

As with any architecture, a team needs to handle the trade-off of having it or don’t it.

• Increases the complexity.
• There is the possibility of duplicate code.
• Adding a new layer impacts the delay layer, that is, the possible loss of performance.

The other option is to add the DTO layer, which basically guarantees the decoupling of the view and the model, as mentioned previously.

• It makes it explicit which fields will go to the view layer. Yes, there are several annotations in various frameworks that indicate which fields will not be displayed. However, if you forget to write it down, you can export a critical field accidentally, for example, the user’s password.
• Facilitates drawing in object orientation. One of the points clean code clarifies object orientation is that OOP hides the data to expose the behaviour, and the encapsulation helps with that.
• Facilitates updating the database. It is often essential to refactor, migrate the database without this change impacting the customer. This separation facilitates optimisations, modifications to the database without affecting the visualisation.
• Versioning, backward compatibility is an important point, especially when you have an API for public use and multiple customers, so it is possible to have a DTO for each version and evolve the business model without worry.
• Another benefit is found in the ease of working with the rich model and creating an API that is bullet-approved. For example, within my model, I can use a money API; however, I export as a simple object with only the monetary value for visualisation within my visualisation layer. That is the right old String in Java.
• CQRS. Yes, is Command Query Responsibility Segregation about separating responsibility for writing and reading data, and how to do this without DTOs?

In general, adding a layer means decoupling and facilitating maintenance at the expense of adding more classes and complexity. We also have to think about the conversion operation between these layers. This is the reason, for example, of the existence of MVC, so it is crucial to understand that everything is based on impact and trade-offs or what hurts in a given application or situation.

A more frequent criticism within the DTOs is at work to perform the conversion. The good news is that there are several conversion frameworks; that is, it is not necessary to make the change manually. In this article, reducing the boilerplate, we will choose one that is the mapstruct.

MapStruct has support for both Spring and CDI. To use Spring IoC, we need to add the componentModelattribute to @Mapper with the value “spring” and for CDI would be “cdi”.

The next step is the service layer that is an abstraction over domain logic. It defines the application’s boundary with a layer of services that establishes a set of available operations and coordinates its response in each process. The sample service will handle with the DTO/entity mapper and request information from the DAO layer. If you’re familiar with the Clean Architecture, the service will work as similarly to use cases.

The last layer in this application is the Controller; it will be how the application will make the resource available. The HTTP verb resources are intuitive and clean to use. Beyond, the strong exception handle is provided by Spring.

The controller and the layers are ready; let’s create an integration test to ensure the code’s behavior.

In the second part of the series, we briefly introduced the concept of service, controller, and integration with the database through the DAO carried out in the first part of the article series. In general, the layers generate a degree of complexity to isolate layers, such as the case of DAO and the DTO. With an application ready and tested with integration tests, the next step would be to run an application from the container with Docker and Docker-composer that will be the third part of this series.

If you enjoy working at a large scale in projects with global impact and if you like a real challenge with Java, feel free to reach out to us at xgeeks! We are growing our team, especially in Java and you might be the next one to join this group of talented people 😉

Check out our social media channels if you want to get a sneak peek of life at xgeeks! See you soon!