왜 Hibernate 를 배 워 야 합 니까?

내 가 했 던 많은 프로젝트 를 하 는 과정 에서 나 는 줄곧 해결 되 지 않 은 문제 가 나 를 괴 롭 히 고 있다.그것 이 바로 지구 층 의 개발 이다.지구 층 의 개발 은 일반적으로 CMP 를 사용 하거나 JDBC+DAO 를 사용한다.CMP 는 말 할 필요 도 없 이 저 에 게 실패 한 실천 입 니 다.JDBC+DAO 에 도 많은 어려움 이 존재 합 니 다.저 는 관계 표를 지구 대상 에 완전 하 게 비 추 는 관 계 를 기록 하기 어렵 습 니 다.이것 은 주로 여러 표 의 관계 가 지구 대상 에 대한 비 추 는 데 직접적 으로 나타 나 지 못 하고 한 표 가 여러 개의 지구 대상 을 비 추 는 것 일 수도 있 습 니 다.여러 개의 표 가 하나의 영구적 인 대상 을 비 추 는 것 일 수도 있 고,표 의 일부 필드 가 하나의 영구적 인 대상 에 비 추 는 것 일 수도 있 지만,다른 필드 는 다른 영구적 인 대상 에 비 추 는 것 일 수도 있다.그리고 이런 문 제 를 다 처리 하 더 라 도 대상 의 방식 에 따라 지구 대상(PO)을 직접 프로 그래 밍 할 수 없습니다.1:N 관계 가 존재 하 는 지구 대상 에 대한 조 회 는 사실은 1+n 번 데이터 베 이 스 를 대상 으로 하 는 SQL 이기 때 문 입 니 다.저 는 한 번 실패 한 지구 층 디자인 을 했 습 니 다.결 과 는 다른 지구 대상 과 관련 된 PO 한 번 의 조 회 는 5n+1 번 sql 이 고 속도 가 느 려 서 안 됩 니 다.마지막 으로 바 텀 디자인 을 전체적으로 수정 해 야 한다.마지막 으로 대상 디자인 을 완전히 버 리 고 표 필드 에 따라 조작 하 는 것 과 같다.그러나 이렇게 하 는 것 은 매우 괴롭다.시스템 의 디자인 은 수요 디자인,시스템 디자인 이 이렇게 꼭대기 에서 내 려 온 것 이기 때문에 결 과 는 상세 한 디자인 단계 에 이 르 렀 다.지구 층 의 매 핑 문제 에 의 해 제한 을 받 아 디자인 방안 을 바닥 에서 위로 수정 하고 과정 에 따라 프로 그래 밍 을 하 는 옛길 로 돌아 가 매우 엉망 이 었 다.나 는 이 문제 에 대해 오랫동안 생각 한 끝 에 이것 이 사실은 매우 전형 적 인 문제 라 는 것 을 깨 달 았 다.대상 과 관계 의 매 핑 문제 이다.실제로 OOP 프로 그래 밍 이 유행 한 후부 터 이 어 려 운 문제 가 존재 하기 때문에 관계 데이터 베 이 스 를 재 설계 하고 대상 데이터 베 이 스 를 바 꾸 자고 제안 한 사람 이 있 지만 실제 관계 데이터 베 이 스 는 도태 되 지 않 아 상부 의 응용 층 에서 해결 방안 을 찾 을 수 밖 에 없다.이때 나 는 내 가 필요 로 하 는 것 이 사실상 ORM 제품 이라는 것 을 알 게 되 었 다.제 가 가장 먼저 생각 했 던 ORM 은 바로 JDO 입 니 다.그래서 저 는 두 개의 JDO 제품 을 다운 받 아서 열심히 공부 하려 고 했 습 니 다.그런데 연 구 를 한 후에 저 는 JDO 에 대해 매우 실망 한 것 을 발 견 했 습 니 다.그 이 유 는 다음 과 같 습 니 다.1.JDO 는 좋 은 오픈 소스 가 없 으 며 좋 은 제품 은 모두 상업 제품 이 고 국내 에서 판매 와 기술 지원 이 없 기 때 문 입 니 다.이 로 인해 JDO 는 공부 에 만 사용 되 고 실제 프로젝트 에 사용 할 수 없 게 되 었 습 니 다.그렇지 않 으 면 소프트웨어 를 고객 에 게 팔 때 그 에 게 외국 의 소프트웨어 제품 을 따로 사 야 한다 고 말 해 야 합 니 다.그리고 국내 에서 기술 지원 이 없 으 면 지속 적 인 문제 가 발생 했 습 니 다.우 리 는 해결 할 수 없습니다.국제 전 화 를 걸 어 문 제 를 해결 하 세 요.당신 은 고객 이 승낙 할 수 있다 고 생각 합 니까?2.JDO 는 경량급 포장 이 아니 라 완전한 지구 층 구 조 를 구축 하려 고 하지만 완선 되 지 않 아서 JDO 가 비교적 무 겁 고 많은 조작 방식 이 번 거 롭 고 이상 하 게 느껴 집 니 다.이것 은 프로그래머 의 학습 과 프로 그래 밍 의 부담 을 가중 시 켰 다.그리고 너무 많이 포장 하면 심각 한 문 제 를 초래 할 수 있다.바로 잘못된 정보 가 발생 하면 디 버 깅 하기 가 매우 어렵다.정확 한 포 지 셔 닝 오류 가 어디 에 있 는 지 알 기 어렵다.포장 이 가 벼 울 수록 문 제 는 쉽게 포 지 셔 닝 되 고 쉽게 해결 되 며 포장 이 무 거울 수록 문제 가 복잡 하고 원인 을 찾 지 못 한다.CMP 는 오류 가 발생 하여 디 버 깅 하기 가 매우 어렵 고 번 거 로 운 좋 은 예 이다.3.JDO 의 기준 이 완선 하지 않 고 중대 한 결함 이 존재 한다.가장 중요 한 문 제 는 PO 가 PM(Hibernate 에 해당 하 는 Session)에서 벗 어 나 지 못 하고 존재 하 는 데 나타난다.이것 은 매우 심각 한 문제 로 프로 그래 밍 할 때 대량의 VO 복사 작업 을 하 게 되 어 매우 번거롭다.또 하나의 중대 한 결함 은 정적 인 POJO 의 Enhancer 입 니 다.실행 기 동적 Enhance 를 실행 할 수 없고 증분 컴 파일 과 디 버 깅 을 할 수 없습니다.프로 그래 밍 과 디 버 깅 은 매우 번 거 롭 습 니 다.매번 에 하나의 도 구 를 함께 실행 하여 POJO 를 Enhance 해 야 합 니 다.그 밖 에 JDOQL 이 완선 되 지 않 고 매 핑 관계 의 표현 이 강하 지 않다 는 등 결함 도 있다.4.JDO 제품 의 분열.이 문제 도 심각 하 다.JDO 1.0 기준의 결함 으로 인해 JDO 2.0 기준 은 아직 기약 이 없다.각 JDO 업 체 들 이 경쟁 에서 두각 을 나타 내기 위해 조작 성과 성능 향상 을 제외 하고 고객 을 유치 하려 면 반드시 자신의 제품 특색 이 있어 야 한다.그러면 1.0 기준의 결함 은 그들 에 게 발휘 하 는 무 대 를 주 었 고 모든 업 체 는 자신 만 의 독특한 해결 방안 으로 기준의 결함 을 해결 할 것 이다.그러나 이것 은 JDO 제품 의 사실상 분열 을 초래 했다.이런 분열 은 어느 정도 까지 심각 합 니까?나 는 간단하게 예 를 들 수 있다.네가 쓴 POJO 는 JDO 의 Enhancer 로 Enhance 를 한 후에 얻 은 PO 를 다른 JDO 제품 에서 뛰 지 못 한다.이 는 그 당시 유 닉 스 의 분열 과 비슷 하 다.결 과 는 바 이 너 리 코드 급 이 호 환 되 지 않 고 C 소스 코드 급 에서 만 호 환 된다.현재 의 JDO 도 이러한 추 세 를 보이 고 있다.앱 서버 의 차이 처럼 Weblogic 에서 개 발 된 EJB 를 Websphere 에 이식 하려 면 반드시 다시 설정 해 야 한다.제 가 생각 하 는 ORM 은 다음 과 같은 특징 이 있 는 것 이 좋 습 니 다.1.오픈 소스 와 무료 License 입 니 다.저 는 필요 할 때 소스 코드 를 연구 하고 소스 코드 를 바 꾸 어 기능 적 인 맞 춤 형 제작 을 할 수 있 습 니 다.2.경량급 포장 은 너무 복잡 한 문 제 를 도입 하지 않 고 디 버 깅 이 쉬 우 며 프로그래머 의 부담 도 줄인다.3.확장 성 이 있 고 API 가 개방 되 며 자체 기능 이 부족 할 때 스스로 번 호 를 바 꾸 어 확장 할 수 있 습 니 다.4.개발 자가 활발 하고 제품 의 안정 적 인 발전 보장 이 있 습 니 다.JDO 를 포기 한 후에 저 는 위의 원칙 에 따라 TopLink,CocoBase,Castor 등 을 제 외 했 고 마지막 으로 Apache OJB 와 Hibernate 를 선 택 했 습 니 다.OJB 의 배 제 는 쉽게 이 루어 집 니 다.하 나 는 문서 가 너무 간단 하고 너무 적기 때 문 입 니 다.둘째,OJB 는 다음 버 전 으로 JDO 를 전면적으로 지원 할 계획 이기 때문에 API 에 중대 한 변동 이 있 을 수 있 기 때문에 현 단계 에서 OJB 를 배 우 는 것 은 잘못된 것 입 니 다.API 가 안정 되면 늦게 공부 하지 않 겠 습 니 다.하 이 버 네 이 트 의 발견 은 우연 한 일 이 었 다.다른 사람 이 JDO 제품 에 대해 언급 했 을 뿐 이 었 다.그러나 내 가 하 이 버 네 이 트 를 연구 하기 시 작 했 을 때 나 는 내 가 꿈 꾸 던 ORM 을 찾 았 다 는 것 을 알 게 되 었 다.하 이 버 네 이 트 는 내 가 위 에서 언급 한 기준 에 완전히 부합 되 는 것 외 에 도 JDO 의 모든 결함 을 해 결 했 고 방식 의 우아 함 도 감탄 을 자아 낸다.Hibernate 의 문서 도 매우 특색 이 있 는 부분 입 니 다.Hibernate 의 기능 소개 만 간단 한 것 이 아니 라 실제 적 으로 지구 층 디자인 의 가장 좋 은 실천 경험 총화 입 니 다.문서 안의 예,문서 안의 정 리 는 모두 가장 좋 은 디자인 의 결정 입 니 다.제 가 열심히 하 이 버 네 이 트 를 읽 은 느낌 은 하 이 버 네 이 트 만 파악 한 것 이 아니 라 지구 층 의 디자인 에 대한 경험 이 크게 늘 었 다 는 것 입 니 다.예전 에는 지구 층 의 디자인 에 그렇게 많은 학문 이 있다 고 생각 한 적 이 없 었 고 이 를 통 해 Gavin 은 정말 큰 소 사람 이라는 것 을 느 꼈 습 니 다.물론 하 이 버 네 이 트 를 가장 재 활용 하 는 이 유 는 하 이 버 네 이 트 는 내 가 완전히 제어 할 수 있 는 소프트웨어 이기 때문이다.Hibernate 의 소스 코드 는 매우 적 고 간결 하 게 썼 습 니 다.저 는 항상 이상 하 게 생각 합 니 다.이렇게 적은 소스 코드 가 이렇게 많은 기능 을 실현 할 수 있다 는 것 은 기적 입 니 다.Hibernate 의 소스 코드 트 리 는 매우 명확 하고 간단 합 니 다.소스 코드 는 읽 기 쉽 습 니 다.저 는 문서 에 언급 되 지 않 은 문제 나 문서 에서 언급 되 었 지만 제 가 잘 모 르 는 부분 에 부 딪 히 면 소스 코드 에서 찾 습 니 다.모든 문제 가 밝 아 지고 Hibernate 의 운행 원리 와 디 테 일 에 대해 잘 알 게 되 었 습 니 다.마치 Hibernate 가 자신 이 쓴 코드 처럼.프로그램 을 어떻게 쓰 는 지 잘 알 고 있 습 니 다.Hibernate 의 운행 효율 이 가장 높 고 메모리 가 가장 절약 되 며 프로그램 에 오류 가 생 겼 습 니 다.어떤 곳 의 문제 인지,어떻게 해결 하 는 지 잘 알 고 있 습 니 다.그래서 하 이 버 네 이 트 를 사용 하 는 것 이 저 를 안심 시 켰 습 니 다.저 는 너무 복잡 한 소프트웨어 가 아니 라 그 자체 의 구조 가 복잡 한 데다 가 오픈 소스 가 없어 서 문제 가 생 겨 도 어떻게 된 일 인지 모 르 겠 습 니 다.