스프링 2.5 환경에서 하이버네이트 사용하기

참조 요약: Spring One 2008 Wokring With Hibernate in a Spring 2.5 Environment

스프링의 HibernateTemplate
(Hibernate 3.1 이전)

– 스프링이 관리하는 트랜잭션을 사용한다.
– 예외 번역 제공

public class HibernateClinic extends HibernateDaoSupport {

}

Native Hibernate DAO
(Hibernate 3.1+_

– 트랜잭션 훅(hook)을 제공한다.
– transactional session을 찾는 로직을 제공할 수 있게 한다. sessionFactory.getCurrentSession()
– 예외 번역 제공 @Repository PersistenceExceptionTranslation post processor
– 순수 하이버네이트 API만 사용할 수 있다.

단위 테스트 종류
– “Logical” 단위 테스트
– 통합 테스트

스프링으로 통합 테스트하기
– DI
– 애플리케이션 컨텍스트 로딩 줄이기
– 자동 롤백
– 하이버네이트 + JDBC 조합

AbstractTransactionalDataSourceSpringContextTests
– Ctrl + Shift + T ATDSSCT
– 애플리케이션 컨텍스트 로딩, 캐슁
– DI
– JdbcTemplate 제공

WAR에서 하이버네이트 VS OSGi 개발
– 일반 WAR 배포
  – SessionFactory가 클래스패스에 도메인 타입들을 찾는다.
  – 저장소(DAO, repositoru)들이 SessionFactory를 사용한다.
– OSGi 개발
  – 여러 도메인 번들로 쪼갠다.
  – SessionFactory는 도메인 타입에 접근해야 한다.
  – 저장소는 SessionFactory에 접근해야 한다.

OSGi 환경에서 하이버네이트
– “infrastructure” 번들
  – SessionFactory 서비스를 제공하고
  – 모든 도메인 타입을 가져온다.
– 여러 도메인 모델
  – 도메인 타입을 공개한다.
  – SessionFactory 서비스를 사용한다.
– Petclinic 예제를 제공한다.

=====

발표에서 다루는 내용이 너무 많아서 다소 산만했습니다. 하이버네이트만 집중적으로 다뤘으면 어땠을까 싶더군요. @Repository 얘기가 나오니까 컴포넌트 스캔 얘기로 새고.. 도메인 객체에 repository 객체 주입하는 얘기가 나오니까 @Configurable이랑 aspectj 얘기로 새고.. 테스트 얘기 나오니까 Test Context 쪽으로 또 얘기가 새버렸다가 나중엔 다시 하이버네이트랑 OSGi 얘기 조금 꺼내고 끝~~

멋진건 54분이라는 짧은 발표 시간 중에도 저렇게 많은 내용과 중간 중간 전부 데모까지 보여줬다는 겁니다.

Spring Architecture – Eberhard Wolff

참조: http://www.parleys.com/display/PARLEYS/Home#slide=1;title=Spring%20Architectures;talk=20676612

아키텍처

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them.

Wikipedia

객체: Information hiding

클래스: 객체의 타입을 정의. White box 재사용.

재사용:

A Software Component is a unit of composition with contractually-specified interfaces and explicit  context dependencies only. A software component can be deployed independently and is subject to composition by third parties.

C. Szyperski: Component Software – Beyond Object-
Oriented Programming, Addison-Wesley, 1999

컴포넌트: note the plugability.
– 계약 같은 인터페이스
– Only 명시적인 의존성
– 독립적인 배포
– 컴포지션
– 결과: 간편한 재사용(black box)
– 결과: 간편한 수정(인터페이스는 놔두고 내부만 바꿀 수 있으니.)

객체는 컴포넌트인가?
– 계약 같은 인터페이스? 있네, public 메소드
– 명시적인 의존성? 없네. 코드 내부에서 암거나 만들 수 있으니까.
– 독립적인 배포? 대부분은 안 돼지.
– 컴포지션? No.

DI를 사용하는 객체는 컴포넌트?
– 계약 기반인가? 응
– 명시적인 의존성? 응 설정하자나. setter/constuctor injection,
– 독립적인 배포? Yes. Everything else is injected
– 컴포지션? Yes. DI 컨테이너를 사용해서 조합하니까.

계층
– 각각의 계층은 하위 계층에만 의존해. -> 더 나은 의존성 관리(계층을 쉽게 바꿀 수 있으니까..)
– Typical technical
– 퍼사드를 사용할 수 있음.

스프링을 사용하는 컴포넌트
– 스프링 설정 파일을 각각의 컴포넌트 별로 만든다.
– 추가적인 기반 설정 파일은 javase.xml로..
– Facade를 인터페이스로 추가하고, bean 설정 파일에서 의존성을 정의한다.
– 각각의 컴포넌트는 JAR 파일로.
– 자신만의 빌드 스크립트를 가지고 있고
– 그들 컴포넌트를 묶을 때는 classpath*을 사용한다.

ApplicationContext applicationContext =
 new ClassPathXmlApplicationContext(
  “classpath*:/config/applicationContext.xml”);

스프링 설정 파일 + Facade 사용했을 때 컴포넌트 체크 리스트
– Contractually-specific 인터페이스? Yes. Facade 사용했으니까.
– Only explicit context depedencies? No. 스프링 빈 의존성이 명시적이지 않을 수도 있다.
– 독립적인 배포 가능? Yes. 설정 파일 + 참조하는 클래스
– A way of composition? Yes. 스프링 DI.

계층은 어떤가?
– ApplicationContext 계층 구조를 사용해서 구현했다.
– DispatcherServlet과 ApplicationContext 같은 예.
– 예제 코드

ApplicationContext environmentApplicationContext =
 new ClassPathXmlApplicationContext(
  “javase.xml”);

ApplicationContext persistenceApplicationContext =
 new ClassPathXmlApplicationContext(
  new String[] { “classpath*:*-persistence.xml” },
 environmentApplicationContext);

ApplicationContext logicApplicationContext =
 new ClassPathXmlApplicationContext(
  new String[] { “classpath*:*-logic.xml” },
  persistenceApplicationContext);

ApplicationContext guiApplicationContext =
 new ClassPathXmlApplicationContext(
  new String[] { “classpath*:*-gui.xml” },
  logicApplicationContext);

Vertical Slices.
– 예제 코드

ApplicationContext environmentApplicationContext =
 new ClassPathXmlApplicationContext(“javase.xml”);

ApplicationContext catalogApplicationContext =
 new ClassPathXmlApplicationContext(
  new String[] { “classpath*:/catalog-*.xml”},
 environmentApplicationContext);

ApplicationContext configuratorApplicationContext =
 new ClassPathXmlApplicationContext(
  new String[] { “classpath*:/configurator-*.xml” },
 catalogApplicationContext);

ApplicationContext trackingApplicationContext =
 new ClassPathXmlApplicationContext(
  new String[] { “classpath*:/tracking-*.xml”},
configuratorApplicationContext);

이후 발표는…
– 스프링 JavaConfig를 사용해서 스프링을 사용해서 컴포넌트 설정 예제
– 스프링 DM을 사용하여 컴포넌트 개발 예제
가 이어집니다.

Spring 2.5 on the Way to 3.0 – 유겐 휄러

참조 : Spring 2.5 on the Way to 3.0

Spring One 2008에서 유겐 휄러의 발표 동영상을 보여줍니다. 별점은. 3.2/5 정도 됩니다. 지난 번에 봤던 Using Spring Security (별점 4/5)보다 평점이 조금 낮네요.

JDK 6 지원
– JDK 1.4, 1.5 호환(1.3은 안 함)
– JDBC 4.0 지원(native connections, LOB 핸들링)
– JMX MXBenas

AspectJ LTW 지원

Java EE 5 지원

JSR-250 애노테이션 지원
– @PostConstruct, @PreDestroy
– @Resource
– self describing.

Further Java EE 5 Annotations
– @WebServiceRef/@EJB
– @TransactionAttrubute
– @PersistenceContext/@PersistenceUnit

Autowiring Annotation
– specific autowiring by type
– @Qualifier

Autodetectable Component
– @Component

@Configurable with AspectJ
– <context:load-time-weaver aspectj-weaving=”on” />
– <context:spring-configured />
– @Configurable

@Transactional with AspectJ
– <context:load-time-weaver aspectj-weaving=”on” />
– <tx:annotation-driven mode=”aspectj” />

Annotated MVC Controllers
– @Controller
– @RequestMapping
– @RequestParam
– @ModelAttribute

Test Context Framework
– @ContextConfiguration
– @TransactionConfiguration
– JUnit 4.4 지원.

Tradeoffs
– 재컴파일(XML 설정 변경은 재컴파일 필요 없다.)
– 설정의 외부화(애노테이션은 클래스를 보면 내용을 알 수 있다.)
– 설정 재정의 가능 여부(애노테이션 설정 바꾸면 컴파일 필요하다.)

Spring 2.5 정리
– Java 5와 Java EE 5 완전 지원
– ApsectJ와 보다 긴밀한 연동
– 애노테이션 설정 강화

The Roadmap for Spring 3.0
– 7월까지 2.5.6
– 8월에 3.0 M1
  – REST 지원
  – 다양한 EL 지원
– Spring 3.0 GA는 4분기 중으로..
=> 흠.. 이미 8월 지난지 오래 됐는데, M1 소식도 못들었네요. 내년 초를 기대해봐야겠네요.

Spring 3: Core Revisions
– Java 5+ 지원
  – 스프링 코어 API에 Generic 적용
– J2EE 1.4+ 호환(웹스피어 6.1, 웹로직 9.2, JBoss 4.2)
– 스프링 EL
– 새로운 커테이너 기능 제공(annotated factory methods)
=> 흠. 제레닉 코드가 코어 API에 들어가면.. 혹시 GenericDAO 같은 거도 스프링이 제공하는건가.. 캬오..

Spring 3 and the Web Space
– 개정된 자바 웹 표준 지원(포틀릿 2.0, 서블릿 3.0)
– REST 지원
– conversation 관리
– 애노테이션 기반 위자드 컨트롤러
=> 스프링 3이 conversation이랑 애노테이션 기반 위자드 마법사를 지원해주면.. 캬오 멋질듯.

Spring 2.5 Mission Continued

Pruning & Deprecation in 3.0
– 가지칠것
  – Commons Attuributes 지원
  – 예전 TopLink API 지원
– deprecation 계획
  – 예전 MVC 컨트롤러 클래스 계층 구조
  – 예전 JUnit 3.8 테스트 클래스 계층 구조
=> 애노테이션 기반 시설 중심으로 가면서 예전 시설은 deprecation.

Spring 3.0 Summary
– REST, EL
– RESTful URI 맵핑, 포틀릿 2.0
– Java 5+, Spring 2.5 환경에서 그대로 호환 가능.

아음.. 발표 시간이 64분인데, 55분동안 2.5 얘기만 하다가 3.0 얘기는 빠르게 지나가 버려서 아쉽습니다. 그래서 별 세개만 줬어요. ㅋㅋ 유겐 횽님 Spring One America에서는 스프링 3.0 얘기 좀 더 해주세요. ㅠ.ㅠ 소스도 배포해 주시구요. 3.0에서 저는 컨버세이션 관리와 위자드 마법사가 제일 궁금해요. 그 다음으로는 코어 API에 추가할 제네릭 클래스들 중에 GenericDao같은 것들도 제공할 것인지도 궁금하구요. 마지막으론 스프링 EL도 궁금한데.. 그건 JSF 확장 기능이겠죠? JSP에서도 사용 가능한건가? 어쨋든 S1A에서 뵙겠습니다. 바이바이