hibenate 게 으 름 로드

http://blog.csdn.net/sanjy523892105/article/details/7071139
 
게 으 름 로드 상세 설명
 
게 으 름 로드 는 Hibernate 에서 자주 사용 하 는 특성 중 하나 입 니 다. 게 으 름 로드 의 원리 와 주의사항 을 자세히 알 아 보 겠 습 니 다.
Load () 방법의 게 으 름 로드 원리
Hibernate 에서 조회 방법 은 두 가지 가 있 는데 그것 이 바로 get () 과 load () 이다. 이 두 가지 방법의 차이 점 은 load () 가 게 으 른 로 딩 의 특성 을 가지 고 있다 는 것 이다.Load () 방법 은 특정한 데 이 터 를 조회 할 때 이 데 이 터 를 지정 한 대상 으로 되 돌려 주지 않 고 이 대상 의 일부 속성 을 사용 해 야 할 때 만 데이터 베 이 스 를 방문 하여 데 이 터 를 얻 는 것 이다.그의 장점 은 프로그램 자체 가 데이터베이스 와 의 빈번 한 상호작용 으로 인 한 처리 속도 가 느리다 는 것 이다.
하나의 Person 류 를 예 로 들 면, 우 리 는 다음 과 같은 조 회 를 작성 합 니 다.

public static void query(int id){  
       Session session=null;  
        try{  
            session=HibernateUtil.getSession();  
            Person person=(Person) session.load(Person.class, id);  
            //System.out.println(person.getName());  
        }catch(HibernateExceptionex){  
            ex.printStackTrace();  
        }finally{  
            if(session!=null){  
               session.close();  
            }  
        }  
    }  

그리고 Hibernate 프로필 에 다음 속성 을 추가 합 니 다

<property name="hibernate.show_sql">true</property>  

이 속성 은 Hibernate 가 실 행 될 때 발생 하 는 모든 SQL 문 구 를 출력 하 는 역할 을 합 니 다.
 
위 방법 을 실행 한 후, 우 리 는 Hibernate 가 검색 어 를 인쇄 하 는 것 을 보지 못 했 습 니 다. 이때 우 리 는 주석 문 구 를 다시 돌려 서 검색 한 person 의 name 을 인쇄 할 수 있 습 니 다.이 때 Hibernate 에서 생 성 된 검색 어 를 보고 person 의 name 속성 을 볼 수 있 습 니 다.이것 이 바로 게 으 름 이다.
  그럼 Hibernate 게 으 름 피 울 때 돌아 오 는 대상 이 비어 있 습 니까?정 답 은 부정 적 입 니 다. 저 희 는 person. getClass () 를 인쇄 하 는 방법 으로 검증 할 수 있 습 니 다. 인쇄 된 결 과 는 null 이 아니 라 Person 뒤에 이상 한 문 자 를 추가 한 클래스 입 니 다.분명 한 것 은 게 으 른 로 딩 대상 이 비어 있 지 않 고 이 대상 의 유형 은 Person 류 가 아 닙 니 다.그렇다면 그 는 도대체 무엇 일 까?
사실 이 현금 화 는 우리 가 그것 을 대리 대상 이 라 고 부 르 는데 이 대상 이 속 한 종 류 는 Person 류 의 하위 클래스 이 고 Hibernate 가 자동 으로 실현 하 는 하위 클래스 이다.이 하위 클래스 의 특징 은 person 대상 의 특정한 속성 을 방문 할 때 데이터베이스 에서 이 대상 에 대응 하 는 데 이 터 를 자동 으로 조회 하고 되 돌려 주 는 것 입 니 다. 이것 이 바로 대상 관계 맵 을 만 들 때 실체 류 가 final 형식 이 되 지 못 하도록 요구 하 는 이유 입 니 다.
  그러나 이 대상 은 하나의 생명 주기 가 있 기 때문에 우 리 는 상술 한 방법 을 다음 과 같이 고 칠 수 있다.

public static Person query(int id){  
       Session session=null;  
       Person person=null;  
        try{  
            session=HibernateUtil.getSession();  
            person=(Person)session.load(Person.class, id);  
            //System.out.println(person.getName());  
        }catch(HibernateExceptionex){  
            ex.printStackTrace();  
        }finally{  
            if(session!=null){  
               session.close();  
            }  
        }  
        return person;  
    }  

이 방법 을 호출 하고 조 회 된 프 록 시 대상 을 되 돌려 줍 니 다. 이 대상 을 되 돌려 준 후 이 대상 의 name 속성 을 인쇄 할 수 있 습 니 다. 이 때 org. hibenate. Lazy InitializationException 이상 을 던 집 니 다.
  이것 은 게 으 른 로 딩 이 이상 을 초기 화 할 수 없다 는 것 입 니 다. 게 으 른 로 딩 을 할 때 대리 대상 을 통 해 데이터 베 이 스 를 조회 하려 면 이 session 이 닫 히 기 전에 해 야 합 니 다.그러나 반드시 session 이 닫 힌 후에 프 록 시 대상 을 사용 해 야 한다 면, Hibernate 에서 프 록 시 대상 을 초기 화 하 는 방법 initialize () 를 정의 하 였 으 며, 이 방법 을 통 해 프 록 시 대상 을 초기 화 할 수 있 습 니 다.
 
주: 프 록 시 대상 의 getId () 방법 과 getClass () 방법 을 사용 할 때 초기 화 할 수 없 는 이상 을 던 지지 않 습 니 다. 이 두 속성 은 데이터 베 이 스 를 조회 하지 않 아 도 되 기 때 문 입 니 다.
 
  게 으 른 로 딩 은 맵 과 집합 속성 을 연결 하 는 작업 에 사용 할 수 있 으 며 게 으 른 로 딩 은 닫 고 열 수 있 습 니 다. 다음은 상황 에 따라 게 으 른 로 딩 을 분석 하 겠 습 니 다.
 
일대일 게 으 름 로드 분석
1 대 1 의 게 으 름 로드 는 자주 사용 되 지 않 습 니 다. 게 으 름 로드 의 목적 은 데이터 베이스 와 의 상호작용 을 줄 이 고 실행 효율 을 높이 기 위해 서 입 니 다. 한편, 1 대 1 관계 에서 메 인 표 의 모든 데 이 터 는 표 의 데이터 베이스 에 만 대응 하고 조회 하 더 라 도 서로 교차 하 는 원 가 를 많이 증가 하지 않 습 니 다. 또한 메 인 표 는 contrained = true 가 있어 서 는 안 되 기 때문에 메 인 표 는 게 으 름 으로 로드 할 수 없습니다.(시계 에서 있 을 수 있다)
 
주: fetch 가 join 으로 설정 되면 게 으 른 불 러 오기 가 실 효 됩 니 다.fetch 의 역할 은 캡 처 방식 이기 때문에 그 는 두 개의 값 을 각각 select 와 join 에 게 물 었 고 기본 값 은 select 입 니 다.즉, join 으로 설정 할 때 그 는 표 정 보 를 join 방식 으로 다시 select 조 회 를 사용 하 는 것 이 아니 라 join 방식 으로 조회 하여 게 으 른 로드 의 실 효 를 초래 하 는 것 이다.
 
다 중 및 다 중 게 으 름 로드 분석
  1 대 1 의 관련 과 달리 한 쌍 이 많 고 한 쌍 이 많은 관련 에서 메 인 표 의 모든 속성 은 표 에 있어 야 할 여러 가지 데이터 에 대해 이 럴 때 게 으 름 을 피 우 는 것 이 매우 효과 적 입 니 다.예 를 들 어 한 부서 에 여러 명의 직원 이 있 는데 게 으 름 피 우지 않 으 면 이 부 서 를 조회 할 때마다 여러 명의 직원 을 조회 하 는데 이것 은 데이터 베이스 와 상호작용 하 는 원 가 를 크게 증가 시 킬 것 이다.그래서 Hbernate 는 기본적으로 게 으 름 을 넣 어 불 러 옵 니 다.이것 이 바로 집합 속성 을 조회 할 때 PersistentIndexed * 형식 대상 을 되 돌려 주 는 이유 입 니 다.그 대상 은 사실 대리 대상 이다.물론 맵 파일 에서 lazy 속성 을 가짜 로 설정 하여 사용 하지 않 을 수 있 습 니 다.
 
다 대 일 게 으 름 로드 분석
  1 대 1 과 1 대 1 의 관계 방식 은 같 지만 Hibernate 에 서 는 1 대 1 이 많 으 며 기본적으로 게 으 름 으로 불 러 옵 니 다.또 주의해 야 할 것 은 게 으 름 로드 는 집합 속성 에 값 이 있 는 지 를 구분 하지 않 는 다 는 것 이다. 값 이 없 더 라 도 게 으 름 로드 를 사용 하 는 것 도 게 으 름 로드 가 완선 되 지 않 은 곳 중 하나 이다.
 
게 으 른 로드 의 세부 확장
  때때로, 우 리 는 session 이 닫 힌 후에 도 게 으 른 로 딩 대상 을 사용 하여 데이터 베 이 스 를 조회 해 야 합 니 다. 이때 우 리 는 대리 대상 을 초기 화 해 야 합 니 다. 그러나 문 제 는 우리 가 초기 화 를 확정 하지 못 한 후에 반드시 이 대상 을 사용 해 야 할 때 어떻게 해 야 합 니까? 이렇게 하면 자원 을 헛되이 낭비 하 는 것 이 아 닙 니까?프 록 시 대상 을 사용 하 는 방법 에 불 값 인 자 를 추가 할 수 있 습 니 다. 프 록 시 대상 을 초기 화 할 필요 가 없 을 때 불 인 자 를 가짜 로 설정 할 수 있 습 니 다.그러나 단점 도 있 습 니 다. 호출 할 때, 특히 다른 사람 이 사용 할 때 매개 변수 가 많 을 수록 방법 학습 원가 가 증가 하기 때문에 고려 하여 처리 하 십시오.
  게 으 른 로 딩 도 일부 간단 한 속성 에 사용 할 수 있 지만 실현 이 복잡 하고 효과 가 뚜렷 하지 않 기 때문에 추천 하지 않 습 니 다.