Loading...
Spring Framework Reference Documentation 7.0.2의 General ORM Integration Considerations의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
이 섹션은 모든 ORM 기술에 적용되는 고려 사항들을 강조합니다. Hibernate 섹션은 더 많은 세부 사항을 제공하며 또한 이러한 기능과 설정을 구체적인 컨텍스트에서 보여줍니다.
Spring의 ORM 통합의 주요 목표는 명확한 애플리케이션 레이어링(어떠한 데이터 액세스 및 트랜잭션 기술과도 함께)과 애플리케이션 객체의 느슨한 결합입니다 — 더 이상 비즈니스 서비스가 데이터 액세스 또는 트랜잭션 전략에 의존하지 않고, 더 이상 하드 코딩된 리소스 조회가 없으며, 더 이상 교체하기 어려운 싱글톤이 없고, 더 이상 커스텀 서비스 레지스트리가 없습니다.
목표는 애플리케이션 객체를 연결하는 하나의 단순하고 일관된 접근 방식을 가지는 것이며, 이 객체를 가능한 한 재사용 가능하게 하고 컨테이너 의존성으로부터 자유롭게 유지하는 것입니다. 개별적인 데이터 액세스 기능은 각각 단독으로 사용할 수 있지만 Spring의 애플리케이션 컨텍스트 개념과 잘 통합되어, XML 기반 설정과 Spring을 인식할 필요가 없는 plain JavaBean 인스턴스들의 상호 참조를 제공합니다.
전형적인 Spring 애플리케이션에서, 많은 중요한 객체는 JavaBeans입니다: 데이터 액세스 템플릿, 데이터 액세스 객체, 트랜잭션 매니저, 데이터 액세스 객체와 트랜잭션 매니저를 사용하는 비즈니스 서비스, 웹 뷰 리졸버, 비즈니스 서비스를 사용하는 웹 컨트롤러 등이 있습니다.
일반적인 비즈니스 애플리케이션은 반복적인 리소스 관리 코드로 가득 차 있습니다. 많은 프로젝트가 자신들만의 솔루션을 만들어 내려고 시도하며, 때로는 프로그래밍 편의를 위해 실패에 대한 적절한 처리를 희생하기도 합니다.
Spring은 적절한 리소스 처리를 위한 단순한 솔루션을 주장하며, JDBC의 경우 템플릿화를 통한 IoC와 ORM 기술의 경우 AOP 인터셉터 적용을 제시합니다.
이 인프라는 적절한 리소스 처리와 특정 API 예외를 체크되지 않는 인프라 예외 계층 구조로 적절히 변환하는 기능을 제공합니다. Spring은 어떠한 데이터 액세스 전략에도 적용 가능한 DAO 예외 계층 구조를 도입합니다.
직접적인
JDBC의 경우, 이전 섹션에 언급된 JdbcTemplate 클래스가
커넥션 처리와 SQLException을
DataAccessException 계층 구조로 적절히 변환하는 기능을 제공하며, 여기에는 데이터베이스별 SQL 오류
코드를 의미 있는 예외 클래스로 변환하는 작업도 포함됩니다.
ORM 기술의 경우, 동일한 예외 변환 이점을 얻는 방법은 다음 섹션을 참조하십시오.
트랜잭션 관리에 관해서는, JdbcTemplate 클래스가 Spring
트랜잭션 지원에 hook-in되어 각각의
Spring 트랜잭션 매니저를 통해 JTA 및 JDBC 트랜잭션 둘 다를 지원합니다.
지원되는 ORM 기술의 경우, Spring은 Hibernate 및 JPA 트랜잭션 매니저뿐만 아니라 JTA 지원을 통해 Hibernate 및 JPA 지원을 제공합니다. 트랜잭션 지원의 세부 정보는 Transaction Management 챕터를 참조하십시오.
DAO에서 Hibernate 또는 JPA를 사용할 때, 퍼시스턴스
기술의 네이티브 예외 클래스를 어떻게 처리할지 결정해야 합니다. DAO는 사용 기술에 따라 HibernateException
또는 PersistenceException의 서브클래스를 throw합니다.
이러한 예외는 모두 런타임
예외이며 선언하거나 catch할 필요가 없습니다. 또한
IllegalArgumentException 및 IllegalStateException을 처리해야 할 수도 있습니다. 이는 caller가 퍼시스턴스
기술 고유의 예외 구조에 의존하지 않는 한 예외를 일반적으로 치명적인 것으로만
취급할 수 있음을 의미합니다.
(optimistic locking failure와 같은) 특정 원인을 catch하는 것은 caller를 구현 전략에 묶지 않고는 불가능합니다. 이러한 트레이드오프는 ORM 기반이 강하거나 특별한 예외 처리(또는 둘 다)를 필요로 하지 않는 애플리케이션에는 허용될 수 있습니다.
그러나 Spring은 @Repository 어노테이션을 통해 예외
변환이 투명하게 적용되도록 합니다. 다음
예제(Java 설정용 하나와 XML 설정용 하나)는 그 방법을 보여줍니다:
1@Repository 2public class ProductDaoImpl implements ProductDao { 3 4 // class body here... 5 6}Copied!
1@Repository 2class ProductDaoImpl : ProductDao { 3 4 // class body here... 5 6}Copied!
1<beans> 2 3 <!-- Exception translation bean post processor --> 4 <bean class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor"/> 5 6 <bean id="myProductDao" class="product.ProductDaoImpl"/> 7 8</beans>Copied!
postprocessor는 자동으로 모든 예외 변환기(PersistenceExceptionTranslator 인터페이스의 구현체)를 찾고
@Repository 어노테이션이 표시된 모든 빈에 어드바이저를 적용하여,
발견된 변환기가 throw된 예외에 대해 적절한 변환을 가로채어 적용할 수 있도록 합니다.
요약하면, Spring-managed 트랜잭션, 의존성 주입, 그리고 (원한다면) Spring의 커스텀 예외 계층 구조로의 투명한 예외 변환의 이점을 유지하면서도, plain 퍼시스턴스 기술의 API와 어노테이션에 기반한 DAO를 구현할 수 있습니다.
Introduction to ORM with Spring
Hibernate