[jdbc] 콜백의 분리와 재활용 4

1.     Com.springsource.junit : junit

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

3.     Mysql-connector : Mysql JDBC

4.     Spring-aop : 스프링 기능 자체의 aop

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

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

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

8.     Spring-dao : EmpltyResultDataAccessException 등 사용을 위한 jar

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

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

11.   Spring-test.jar

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

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

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

 

 

전략(바뀌는 부분 쿼리) 인터페이스

고정적인 부분 커넥션 맺고 닫음(Context)

*  인터페이스를 사용안하고 구체클래스로 구현한 이유

>  JDBC 방식 대신 JPA나 하이버네이트 같은 ORM을 사용해야 한다면, JdbcContext도 통째로 바뀌어야 하므로 다른 구현으로 대체해서 사용할 이유가 없다. 이런 경우 드물게 인터페이스를 두지 말고 강력한 결합을 가진 관계를 허용한다.

* 템플릿 : 어떤 목적을 위해 미리 만들어둔 모양있는 틀(모양자). 바뀔수 있는 부분(전략)을 넣어서 사용(14. workWithStatementStrategy())

* 콜백 : (19.makePrepareStatement(콜백)) : 템플릿(JdbcContext)안에서 호출되는 것을 목적으로 만들어진 오브젝트. (시스템 > 사용자를 호출)실행되는 것을 목적으로 다른 오브젝트의 메소드에 전달되는 오브젝트. 자바에서는 메소드 자체를 파라미터로 전달할 방법이 없기 때문에 메소드가 담긴 오브젝트를 전달해야함.(functional object). 좀 더 구체적인 설명은 UserDao 부분 참조

 

 

18. 수동DI : UserDao(클라이언트) 내부에서 직접 DI를 적용. DAO마다 JdbcContext하나가 만들어진다. 스프링 빈으로 생성한게 아니므로 싱글톤을 포기한다.

> UserDao메서드에서는 JdbcContext가 외부에서 빈으로 만들어져 주입된 것인지, 내부에서 직접 만들고 초기화한 것인지 구분할 필요도 없고 구분할 수도 없다. JdbcContext를 사용하면 됨.

24~34. 콜백 : 템플릿(JdbcContext.workWith~~) 안에서 호출되는 것을 목적으로 만들어진 오브젝트. 자바는 메서드 자체를 인자값으로 던질 수 없으므로 오브젝트로 대신

* 장점

- DI의 근본적인 원칙에 부합하지 않는 구체적인 클래스와의 관계가 설정에 직접 노출된다.

- 관계를 외부에 드러내지 않는다. UserDao 클래스 파일에 녹여져 있기 때문에

* 일반적으로 어떤 방법이 더 낫다고 이야기 할 수 없다. 상황에 따라 적절하다고 판단되는 방법을 선택해서 사용하면 된다. 하지만 분명한 이유와 근거가 있어야 한다. 분명히 설명할 자신이 없다면 차라리 인터페이스를 만들어서 평범한 DI구조로 만드는게 낫다.

 

바뀌는 부분과 변하지 않는 부분을 분리

메소드를 통틀어서 바뀔 수 있는 부분은 delete from users

 

* 템플릿/콜백 패턴 : 전략 패턴과 DI의 장점을 익명 내부 클래스를 사용 전략과 결합한 활용법. 일반적인 DI라면 템플릿에 인스턴스 변수를 만들어 두고 사용할 의존 오브젝트를 수정자 메서드로 받아서 사용할 것이다. 하지만, 매번 메소드 단위로 사용할 오브젝트를 새롭게 전달 받는 것이 특징. 메소드 레벨에서 일어나는 DI

59. excuteSql 메소드는 UserDao만 사용하기엔 아까운 재사용 가능한 콜백을 담고 있는 메소드라면 DAO가 공유할 수 있는 템플릿 클래스 안으로 옮겨도 된다. 아래 예시 참조

 

 

콜백과 템플릿의 결합

28. excuteSql 메소드는 UserDao만 사용하기엔 아까운 재사용 가능한 콜백을 담고 있는 메소드라면 DAO가 공유할 수 있는 템플릿 클래스 안으로 옮겨도 된다. 엄밀히 말해 템플릿은 JdbcContext가 아닌 workWithStatementStrategy() 메소드 이므로, 재사용가능한 메소드를 옮긴다해도 문제될 것은 없음. 템플릿과 콜백의 공존

* 일반적으로 성격이 다른 코드들은 가능한 분리하는 편이 낫지만, 하나의 목적을 위해 서로 긴밀하게 연관되어 동작하는 응집력이 강한 코드들이기에 한군데 모여있는게 유리하다.

* 구체적인 구현과 내부의 전략 패턴, 코드에 의한 DI, 익명 내부 클래스 등의 기술은 최대한 감춰두고 외부에는 꼭 필요한 기능을 제공하는 단순한 메서드만 노출

 

18. 수동DI : 관계를 외부(설정파일)에 드러내지 않는다. DI의 기본 원칙에 부합하지 않는 구체적인 클래스와의 관계가 노출되므로. 스프링 DI로 해도 관계없음

 

 

하지만 이제 스프링의 JdbcTemplate를 사용할 것이다. 우리가 만든 JdbcContext보다 훨씬 많은 JDBC 사용을 위한 템플릿과 콜백 오브젝트를 제공한다.