Introduction to Spring Boot and JDBCTemplate: Refactoring to SpringData JPA

Refactoringistheprocessofmodifying a software system withoutchanging its desirablebehavior. It wasnecessarytohaveanapplicationintegratedwiththerelationaldatabaseusingthe Spring JDBC Template in thefirstparts. The Spring JDBC Templateis a powerful tool thatfacilitatesproductivity. However, thereis a waytosimplifythecodeevenfurtherwith Spring Data JPA. The purposeofthis post istorefactortheprojectto use Spring Data JPA.

Spring Data JPA, partofthelarger Spring Data family, makes it easytoimplement JPA-basedrepositorieseasily. This module dealswithenhancedsupport for JPA-based data accesslayers. It makes it easierto build Spring-poweredapplicationsthat use data accesstechnologies.

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.