Introduction to Spring Boot and JDBCTemplate: Refactoring to SpringData JPA

Refactoring is the process of modifying a software system without changing its desirable behavior. It was necessary to have an application integrated with the relational database using the Spring JDBC Template in the first parts. The Spring JDBC Template is a powerful tool that facilitates productivity. However, there is a way to simplify the code even further with Spring Data JPA. The purpose of this post is to refactor the project to use Spring Data JPA.

Spring Data JPA, part of the larger Spring Data family, makes it easy to implement JPA-based repositories easily. This module deals with enhanced support for JPA-based data access layers. It makes it easier to build Spring-powered applications that use data access technologies.

A safe code refactoring requires the use of tests to ensure that the compartment is not changed. The use of tests, fortunately, is adopted as a minimum standard, including several methodologies such as TDD that preach the creation of tests at the beginning of the development process.

The first step in refactoring is the dependency upgrade to use Spring Data JPA.

<dependency> 

    <groupId>org.springframework.boot</groupId> 

    <artifactId>spring-boot-starter-data-jpa</artifactId> 

</dependency> 

JPA is an annotation-driven framework, thus, it will put annotations in the Car entity.

xxxxxxxxxx

@Entity 

public class Car { 

    @Id 

    @GeneratedValue(strategy= GenerationType.IDENTITY) 

    private Long id; 

    @Column 

    private String name; 

    @Column 

    private String city; 

    @Column 

    private String model; 

    @Column 

    private String color; 

} 

These annotations will reduce the boilerplate, and it will remove the RowMapper implementation. The next step is to delete the DAO class and use the repository interface instead. Spring Data repository abstraction aims to significantly reduce the amount of boilerplate code required to implement data access layers for various persistence stores. 

xxxxxxxxxx

public interface CarRepository extends PagingAndSortingRepository<Car, Long> { 

}

We'll replace the DAO to use CarRepository instead in the service layer. Yeap, both DAO and Repository will decouple the service with the data abstraction. However, they are different. 

xxxxxxxxxx

@Service 

public class CarService { 

    private final CarRepository repository; 

    private final CarMapper mapper; 

    @Autowired 

    public CarService(CarRepository repository, CarMapper mapper) { 

        this.repository = repository; 

        this.mapper = mapper; 

    } 

    public List<CarDTO> findAll(Pageable page) { 

        Stream<Car> stream = StreamSupport 

                .stream(repository.findAll(page) 

                        .spliterator(), false); 

        return stream.map(mapper::toDTO) 

                .collect(Collectors.toList()); 

    } 

    public Optional<CarDTO> findById(Long id) { 

        return repository.findById(id).map(mapper::toDTO); 

    } 

    public CarDTO insert(CarDTO dto) { 

        Car car = mapper.toEntity(dto); 

        return mapper.toDTO(repository.save(car)); 

    } 

    public CarDTO update(Long id, CarDTO dto) { 

        Car car = repository.findById(id) 

                .orElseThrow(() -> new EntityNotFoundException("Car does not find with the id " + id)); 

        car.update(mapper.toEntity(dto)); 

        repository.save(car); 

        return mapper.toDTO(car); 

    } 

    public void delete(Long id) { 

        repository.deleteById(id); 

    } 

} 

Spring Data dramatically simplifies the code, motivating the migration of this framework instead of Spring JDBC. In our simple example, with the migration, there was a reduction of three entire classes. This reduction of code tends to increase as the queries become more complex, for example, work with several join combinations.