7. 7
고민과 좌절
하나의 클래스와 하나와 테이
블은
매핑할 수 있겠는걸 ..
Order 와 연관된 Address 객
체를
ORDER 테이블에 넣어야 하
나 ?
쿼리를 두번 날려 ?
상속은 어떻게 구현하지
?
Order 를 로딩할 때 ,
OrderItem 도
함께 로딩할까 ? 매번하면
성능이 나빠질텐데 ,,,,,
트랜잭션의 처리는
?
어려워
ㅜㅜ
9. 9
POJO 의 반격
POJO 진영의 반격
Procedural
힘내라
나
ORM
Lightweight
Container
Open Source
10. 10
솔루션의 선택
ORM: Hibernate
Container: Spring
“JPA 는 향후 고려 예정„
• POJO 기반
• Hibernate/JPA 연동
• 선언적 트랜잭션 지원
• JTA 지원
• 다양한 제품과 연동 용이
• 풍부한 객체 지향 개념 지원
• POJO 기반
• HQL, Criteria, Native SQL
• JTA 를 통한 트랜잭션 관리 가능
• 다양한 방법으로 성능 향상 가능
11. 11
POJO 기반 구현
도메인 모델의 구성 요소
아키텍처
Entity 의 구현
ORM 처리
구성 요소의 조립
Repository 의 구현
선언적 트랜잭션
동시성 제어
JTA 연동
성능
12. 12
도메인 모델의 구성 요소
Entity
고유의 identity 를 갖는 객체
DB 테이블과 매핑되는 객체
비즈니스 로직을 포함
Value Object
값을 표현하는 객체로서 고유의 identity 를 갖지 않는다 .
Entity 에 포함되는 value object 와 뷰 영역을 위한 value object 로 구분 가능 .
Repository
entity 를 검색하고 삭제하기 위한 메소드를 정의한다 .
persistence 레이어를 캡슐화한다 .
Service
어플리케이션의 흐름을 구현한다 .
여러 객체를 사용하여 구현되는 기능을 제공한다 .
서비스는 하나의 entity 로 구현할 수 없는 기능을 포함한다 .
Use Case 와 연관된다 .
Factory
객체 그래프에 맞게 객체들을 조립하여 생성
Façade
Presentation 영역과 도메인 영역을 연결
17. 17
Repository 의 구현
Hibernate 를 이용한 Repository 의 구현
Spring 의 HibernateDaoSupport 이용
18. 18
선언적 트랜잭션
Façade 의 메소드에 트랜잭션 적용
Spring 의 AOP 를 이용하여 선언적 트랜잭션 구현
Façade, Service, Repository 는 트랜잭션 처리로부터 해방
19. 19
Hibernate 의 동시성 제어
Optimistic Locking
version 기반 Optimistic Locking 지원
Pessimistic Locking
행 단위의 락킹 지원
Offline Optimistic Locking
Hibernate 의 detached object 를 사용하여 구현
20. 20
JTA 연동
JTA 를 이용한 트랜잭션 처리
JOTM 과 같은 오픈 소스 JTA 구현체 사용
J2EE 콘테이너가 제공하는 JTA 연동 가능
JTA 를 통한 DB 커넥션과 다양한 자원의 트랜잭션 처리 가능
21. 21
Hibernate 와 성능 (1)
Lazy Loading
연관된 객체를 필요한 순간에 로딩
불필요한 select 쿼리 및 join 을 수행하지 않음
Eagarly loading: 객체를 로딩한 후 연관된 객체를 함께 로딩
Join Fetch
inner join, outer join 등을 이용하여 연관된 객체를
하나의 SELECT 쿼리로 로딩
Lazy Loading vs Join Fetch
기본 : Lazy Loading 을 사용하여 필요한 쿼리만 수행하는 것이 유
리
적은 수의 객체 : join 을 사용하여 연관된 객체를 함께 로딩함으로
써
수행되는 쿼리의 개수를 줄임
22. 22
Hibernate 성능 (2)
2 차 캐시
어플리케이션 단위의 캐시 : 모든 Session 이 캐시 공유
분산 캐시 지원 : 클러스터 단위로 캐시 공유
Lazy Loading 을 사용할 경우 2 차 캐시가 유리
쿼리 캐시
HQL, Criteria 등 검색 결과를 캐시에 저장
캐시와 성능
DBMS 에 대한 접근을 최소화 함으로써 조회 성능 ( 속도 ) 을 대폭
향상
게시판 , 블로그처럼 최근 데이터가 자주 사용되는 어플리케이션에
서
특히 높은 효과를 볼 수 있음
23. 23
성능에 대하여
최고의 성능 vs. 적절한 최상의 성능
최고의 성능 : Java < C < 어셈블리 < 기계어
최고의 성능 : ORM < 단순 매핑 < pure JDBC
최고 보다는 적절한 최상의 성능을 추구
95% 의 ORM
POJO 에서는 무조건 100% ORM 이라는 생각은 위험함
일부 고성능이 필요한 곳에서는 pure JDBC 나 캐시 기법 등 적용
POJO 의 보상 1: 생산성 향상
SQL 및 자원 관리와 관련된 코드를 없앰으로써 생산성 ( 대폭 )
향상
빠른 개발과 일부 코드에 대한 튜닝
POJO 의 보상 2: 유지보수성 향상
전체적인 코드 라인수가 감소
비즈니스 로직에 초점이 맞춰진 코드
24. 24
참고자료
POJO
POJO 의 유래 : http://www.martinfowler.com/bliki/POJO.html
POJO in Action, Chris Richardson, Manning
Hibernate
http://www.hibernate.org
Java Persistence with Hibernate, Christian Bauer 외 , Manning
Hibernate 3 프로그래밍 , 최범균 , 가메출판사 (3 월 )
Spring
http://www.springframework.org
스프링 인 액션 , Craig Walls 외 , 에어콘출판사 [Manning]
오픈소스 JTA 구현체
JOTM(Java Open Transaction Manager) : http://jotm.objectweb.org/
객체 지향 및 패턴 관련
OOAD: http://www.ooad.org
Domain Driven Design, Eric Evans, Addison-Wesley Professional
강의 예제 코드
http://cafe.daum.net/jco8pojo
- 처음 웹 개발자의 길로 들어서면 JSP 에서 모든 걸 처리하는 것 부터 시작함 - 좀더 공부를 하다보면 JSP 와 로직을 처리하는 코드를 분리하는 것이 좋다고 말하는 것을 듣게 되고 , 이에 따라 스트러츠와 같은 프레임워크를 이용하여 MVC 패턴을 도입하게 된다 . 더불어 , 자바빈을 사용하여 데이터를 표현하게 된다 . - 좀더 하다보면 선배들이 DAO 패턴을 이용하여 DB 처리 관련 코드를 분리해내는 것을 보게 되고 , iBATIS 와 같은 것을 사용해서 좀더 편리하게 처리할 수 있따는 것도 알게 된다 . - 그 이후 발전은 , 이 패턴을 잘 사용할 수 있도록 도와주는 프레임워크의 사용법을 익히는 데 초점이 맞춰진다 .