[spring] xml_jaxb적용_빈후처리기_context네임스페이스_3

1.     Com.springsource.javax.activation : Spring java-mail

2.     Com.springsource.javax.mail : Spring java-mail

3.     Com.springsource.org.aopalliance : Spring ProxyFactoryBean

4.     Com.springsource.org.aspectj.tools : AspectJExpressionPointcut 포인트컷 표현식 지원

5.     Com.springsource.junit : junit

6.     Commons-logging : Spring-context가 사용

7.     Mail : java-mail

8.     Mockito : 목 프레임워크 중 Mockito

9.     Mysql-connector : Mysql JDBC

10.   Org.springframework.context.support : Spring java-mail

11.   Spring-aop : 스프링 기능 자체의 aop, Spring ProxyFactoryBean

12.   Spring-bean : 스프링 빈을 활용하는 경우 필요. 스프링의 XML 설정파일과 자바 애노테이션을 파싱 하는데 필요한 클래스 포함

13.   Spring-context : 스프링 코어를 확장한 많은 클래스가 들어 있는데 모든 클래스는 EJB, JNDI(Java Naming Directory Interface), JMX용 클래스와 연동하는데 applicationcontext기능을 사용해야 하며 스프링 리모팅 클래스, 동적 스크립팅 언어(제이루비, 그루비등)와 연동하는 클래스, 빈 유효성검증(JSR-303) API, 스케줄링을 하는 클래스도 포함되어 있다.

14.   Spring-core : 모든 스프링 모듈에서 필요한 모듈. 다른 스프링 모듈에서 사용하는 공통 클래스가 포함됨.

15.   Spring-expression : 스프링 표현언어(SpEL) 지원 클래스 포함.

16.   Spring-jdbc : 스프링이 지원하는 jdbc.

17.   Spring-test.jar

-       @RunWith : Junit 프레임워크의 테스트 실행방법을 확장시 사용.

-       SpringJUnit4ClassRunner : 어플리케이션컨텍스트를 만들고 관리하는 확장 클래스

-       @ContextConfiguration(경로) : 자동으로 만들어줄 어플리케이션 컨텍스트 설정파일

18.   Spring-tx : DuplicateKeyException.class 파일 존재 및 스프링 트랜잭션

 

레벨의 역할(다음레벨 셋팅 및 전달)은 레벨에게 위임

 

 

User의 역할은 User에게 User 레벨셋팅

 

JAXB sql 엘리먼트 domain

 

 

Jaxb Sqlmap 엘리먼트 domain

 

 

JPA, Hibernate, JDBC, JDO 와 같이 변할 수 있으므로 인터페이스

 

JDBC 구현

 

쿼리 DAO와 분리 DBA에 의한 SQL 리뷰나 튜닝 필요시 해당 파일만 전달. SQL 내용을 변경하더라도 어플리케이션 코드나 DI 설정은 전혀 수정할 필요가 없어짐.

독립적인 파일 XML이 편리한 포맷

 

 

6,12,13. Context 네임스페이스를 통해 사용되도록 정의

47. context:annotation-config : 트랜잭션 빈후처리기편 처럼 일일이 빈을 등록해도 되지만, 해당 태그를 설정파일에 넣어주면 특별한 어노테이션 기능을 부여해주는 빈 후처리기들이 등록된다.

(이 예제에서는 XmlSqlService의 @PostConstruct를 생성자처럼 후처리기를 위해 사용)

transactionManager : tx:advice 에 주입해줘야하지만 id가 transactionManager이면 생략가능.

041. AOP 트랜잭션 인터셉터 전파속성 편 참조

 

Jaxb가 아닌 혹은 XML이 아닌 다른 방식이 들어올 수 있고, 데코레이터 패턴 프록시 등이 사용될 수 있으므로 여러모로 인터페이스가 좋다.

 

23. @PostContruct : XmlSqlService는 생성 및 초기화 제어권이 스프링에 있다. 따라서 스프링에서는 미리 지정한 초기화 메소드를 호출해주는 기능을 가지고 있다.(빈후처리기가 감지하는 어노테이션). JDK6에 포함된 표준 어노테이션이지만, 스프링은 빈오브젝트의 초기화 메소드를 지정하는데 사용된다.

* 생성자에서 예외가 발생할 수도 있는 복잡한 초기화 작업을 다루는 것은 좋지 않다. 생성자에서 발생하는 예외는 다루기 힘들고(잘못된 인스턴스 생성), 상속하기 불편하며(생성자는 자바 클래스의 멤버가 아니므로 상속되지 않는다. 따라서 오버라이딩의 대상이 될 수 없다. 일반 메소드 호출방법으로 호출할 수 없다.), 보안에 문제가 생길 수 있다. 초기 상태를 가진 오브젝트를 만들어놓고 별도의 초기화 메소드를 사용하는 방법이 바람직하다.

* 또한 XML 파일의 위치와 이름을 코드에 고정하는 건 별로 좋은 생각이 아니다. 코드의 로직과 여타 이유로 바뀔 가능성이 있는 내용은 외부에서 DI로 설정해줄 수 있게 만들어야한다.

 

* 충분히 잘만들어졌지만 만족할 수 없다.

- 현재 이 서비스는 특정포맷의 XML에서 SQL 데이터를 가져오고, 이를 HashMap에 저장한다.

1) XML 대신 다른 포맷의 파일에서 SQL을 읽어오는 것이라면?

> 구현체를 새로 만들거나, XmlSqlService를 뜯어고쳐야 한다.

2) 가져온 SQL정보를 HashMap 타입 컬렉션이 아닌 다른 방식으로 저장한다면?

- 위처럼 XmlSqlService가 변경되는 이유가 두 가지라면 이는 단일책임 원칙을 위반하는 셈이다. 그렇다고 한가지 기술의 변화 때문에 아예 새로운 구현체를 만들면 상당 부분의 코드가 중복되는 결과를 초래할 것이다.

- SQL을 가져오는 것, 보관해두고 사용하는 것은 충분히 독자적인 이유로 변경이 가능한 독립적인 전략이다. 서로 변하는 시기와 성질이 다른 것, 변하는 것과 변하지 않는 것을 함께 두는 건 바람직한 설계구조가 아니다. 다음편 마이그레이션해보자.

 

 

 

 

 

 

데코레이터패턴, 프록시를 위한 인터페이스.

*  트랜잭션  경계설정의 일원화(하나로 만듬)

>  비즈니스 로직을 담고 있는 서비스 계층 오브젝트에 트랜잭션 경계를 부여하기에 가장 적절한 대상이다.

-       현재 코딩되어있는 add 메서드 처럼 부가 로직을 적용할 수 있고, 트랜잭션 속성도 제어할 수 있기 때문이다.

>  예를 들어 UserService가 아니라면 UserDao를 직접 사용하지 않고, UserService를 사용하는 것이 바람직하다. 단순 조회나 간단한 수정이라면 직접 UserService외의 서비스 계층 오브젝트에서 UserDao를 사용해도 상관없다. 하지만 등록이나 수정, 삭제가 포함된 작업이라면 다른 모듈의 DAO를 직접 이용할 때 신중을 기해야 한다. 안전하게 사용하려면 다른 모듈의 서비스 계층을 통해 접근하는 방법이 좋다.(트랜잭션 모두 취소 혹은 모두 성공)

-   단순히 레코드 개수를 리턴하는 getCount()를 제외하면 나머지는 독자적인 트랜잭션을 가지고 사용될 가능성이 높다. 따라서 이 4개의 메소드를 추가함.

 

 

타겟 서비스 구현

 

 

메일서버 과부하를 막기위한 테스트 스텁

 

DB 접속불가를 위한 목오브젝트를 이용한 테스트

 

 

목 오브젝트 생성과 add 테스트

 

 

트랜잭션 테스트

 

번거롭게 목, 스텁 오브젝트를 생성하지 않고, 목 프레임웍을 활용한 테스트