Spring Data편의점은 JPA많은 것들을 추상화하고 지속성 저장소 액세스에 Spring의 마법을 가져옵니다. 주로 관계형 데이터베이스 작업에 사용됩니다. 즉, findByNameOrderByAge(String name);런타임에 구문 분석되고 적절한 JPA쿼리 로 변환 될 수 있는 메소드가있는 인터페이스를 선언 할 수 있습니다 .

그것의 배치 JPA는 다음에 대한 유혹을 만듭니다 :

1. 잘 모르 SQL거나 모르는 신인 개발자 . 이것은 재난에 대한 레시피이지만 프로젝트가 사소한 경우에는 벗어날 수 있습니다.

2. 자신이하는 일을 알고 일을 빠르게 시작하려는 숙련 된 엔지니어. 이것은 실행 가능한 전략 일 수 있습니다 (그러나 더 읽으십시오).

에 대한 나의 경험에서 Spring Data마술이 너무 큽니다 ( Spring일반적으로 적용 가능함 ). 나는 하나의 프로젝트에서 그것을 많이 사용하기 시작했고 결국 라이브러리를 방해 할 수 없었고 추악한 해결책으로 끝나는 몇 가지 모퉁이 사건을 겪었습니다. 나중에 다른 사용자의 불만 사항을 읽고이 문제가에 대한 것임을 깨달았습니다 Spring Data. 예를 들어, 몇 시간 동안 조사 / 맹세를 유발 한이 문제를 확인하십시오.

 public TourAccommodationRate createTourAccommodationRate(
        @RequestBody TourAccommodationRate tourAccommodationRate
    ) {
        if (tourAccommodationRate.getId() != null) {
            throw new BadRequestException("id MUST NOT be specified in a body during entry creation");
        }

        // This is an ugly hack required for the Room slim model to work. The problem stems from the fact that
        // when we send a child entity having the many-to-many (M:N) relation to the containing entity, its
        // information is not fetched. As a result, we get NPEs when trying to access all but its Id in the
        // code creating the corresponding slim model. By detaching the entity from the persistence context we
        // force the ORM to re-fetch it from the database instead of taking it from the cache

        tourAccommodationRateRepository.save(tourAccommodationRate);
        entityManager.detach(tourAccommodationRate);
        return tourAccommodationRateRepository.findOne(tourAccommodationRate.getId());
    }

나는 더 낮은 레벨로 올라 갔고 사용하기 시작했습니다 JDBI. 이를 통해 SQL 쿼리를 완벽하게 제어 할 수 있으며 라이브러리와 싸울 필요가 거의 없습니다.

답변