답변:
Hibernate는 JPA 구현이고 Spring Data JPA는 JPA 데이터 액세스 추상화입니다. Spring Data JPA는 JPA 제공자없이 작동 할 수 없습니다.
Spring Data는 DDD Repository패턴 또는 레거시 GenericDao사용자 정의 구현에 대한 솔루션을 제공합니다 . 또한 메소드 이름 규칙을 통해 JPA 쿼리를 생성 할 수도 있습니다.
Spring Data를 사용하면 Hibernate, Eclipse Link 또는 기타 JPA 제공자를 사용할 수 있습니다. Spring 또는 Java EE를 사용하면 매우 흥미로운 이점은 주석을 사용하여 트랜잭션 경계를 선언적으로 제어 할 수@Transactional 있다는 것 입니다.
Spring JDBC는 훨씬 가벼우 며 기본 쿼리를 위해 만들어졌으며 JDBC 만 사용하려는 경우 Spring JDBC를 사용하여 JDBC 상세 정보를 처리하는 것이 좋습니다.
따라서 최대 절전 모드와 스프링 데이터는 경쟁사보다는 보완 적입니다.
우리가 여기서 사용하고있는 3 가지 다른 것들이 있습니다 :
스프링 데이터 JPA와 스프링 + 최대 절전 모드가 어떻게 작동하는지 이해 하자.
애플리케이션에 spring + hibernate를 사용한다고 가정 해 봅시다. 이제 최대 절전 모드의 SessionFactory를 사용하여 crud 작업을 작성하는 dao 인터페이스 및 구현이 필요합니다. 내일 Employee 클래스에 대한 dao 클래스를 작성한다고 가정 해 봅시다. 내일 응용 프로그램에서 다른 엔티티에 대해 비슷한 crud 작업을 작성해야 할 수도 있습니다. 여기에 보일 수있는 상용구 코드가 많이 있습니다.
이제 Spring 데이터 jpa를 사용하면 리포지토리 (crudrepository, jparepository)를 확장하여 dao 인터페이스를 정의 할 수 있으므로 런타임에 dao 구현을 제공합니다. 더 이상 dao 구현을 작성할 필요가 없습니다. 이것은 스프링 데이터 JPA가 삶을 쉽게 만드는 방법입니다.
SpringJPA에 동의하지 않으면 쉽게 살 수 있습니다. 예, 일부 클래스를 제공하며 간단한 DAO를 빠르게 만들 수 있지만 실제로는 할 수있는 모든 것입니다. findById () 이상의 작업을 수행하거나 저장하려면 지옥을 거쳐야합니다.
자체 트랜잭션 관리가 단점 인 이유는 무엇입니까? Java 1.8은 기본 메소드를 인터페이스, Spring 어노테이션 기반 트랜잭션으로 허용하므로 단순하게 작동하지 않습니다.
불행히도 SpringJPA는 리플렉션을 기반으로하며 때로는 메소드 이름이나 엔티티 패키지를 주석 (!)으로 가리켜 야합니다. 리팩토링이 큰 충돌을 일으키는 이유입니다. 슬프게도 @Transactional은 기본 DS에서만 작동합니다. (따라서 둘 이상의 데이터 소스가있는 경우 트랜잭션은 기본 소스에 대해서만 작동합니다.)
Hibernate와 Spring Data JPA의 주요 차이점은 무엇입니까?
Hibernate는 JPA 호환, SpringJPA Spring 호환입니다. SpringJPA를 Spring-SpringBoot에서 사용할 수있는 경우 HibernateJPA DAO를 JavaEE 또는 Hibernate Standalone과 함께 사용할 수 있습니다.
언제 Hibernate 또는 Spring Data JPA를 사용해서는 안됩니까? 또한 Spring JDBC 템플릿은 언제 Hibernate / Spring Data JPA보다 성능이 좋을까요?
많은 조인을 사용해야하거나 여러 데이터 소스 연결이있는 Spring을 사용해야하는 경우에만 Spring JDBC를 사용하십시오. 일반적으로 조인용 JPA는 피하십시오.
그러나 나의 일반적인 조언은 신선한 솔루션 인 Daobab ( http://www.daobab.io )을 사용하는 것입니다. Daobab은 저의 Java 및 JPA 엔진 통합 자이며, 여러분의 작업에 많은 도움이 될 것이라고 믿습니다. :)
Spring Data편의점은 JPA많은 것들을 추상화하고 지속성 저장소 액세스에 Spring의 마법을 가져옵니다. 주로 관계형 데이터베이스 작업에 사용됩니다. 즉, findByNameOrderByAge(String name);런타임에 구문 분석되고 적절한 JPA쿼리 로 변환 될 수 있는 메소드가있는 인터페이스를 선언 할 수 있습니다 .
그것의 배치 JPA는 다음에 대한 유혹을 만듭니다 :
잘 모르 SQL거나 모르는 신인 개발자 . 이것은 재난에 대한 레시피이지만 프로젝트가 사소한 경우에는 벗어날 수 있습니다.
자신이하는 일을 알고 일을 빠르게 시작하려는 숙련 된 엔지니어. 이것은 실행 가능한 전략 일 수 있습니다 (그러나 더 읽으십시오).
에 대한 나의 경험에서 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 쿼리를 완벽하게 제어 할 수 있으며 라이브러리와 싸울 필요가 거의 없습니다.