[jdbc]전략패턴_context분리3

 

전략(변하는 부분 SQL) 인터페이스

 

1.     다른 DAO들도 사용 가능하도록 클래스 밖으로 독립

11.   Setter : JdbcContext가 DataSource를 의존하고 있으므로 DI받을 수 있도록 세팅

*  구체화 클래스로 만든 이유 : 스프링 DI는 기본적으로 인터페이스를 사이에 두고 의존 클래스를 바꿔서 사용하도록 하는 것이 목적.

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

 

19. jdbcContext DI의 필요성

> 싱글톤으로 생성됨(스프링 자체) 메모리 절약

> DI를 위해서는 주입받는 오브텍트와 주입하는 오브젝트 양쪽 모두 스프링 빈으로 등록되어야 하기 때문. JdbcContext는 다른 빈을 DI받기 위해서라도 스프링 빈으로 등록되어야함.

 

 

16~22. 비록 런타임시 DI방식으로 외부에서 오브젝트를 주입해주는 방식을 사용하지만, 의존 오브젝트(JdbcContext)의 구현 클래스는 변경할 수 없다.

 

 

 

 

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

 

 

고정적인 부분 커넥션 맺고 닫음(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구조로 만드는게 낫다.

 

58~65. 콜백은 일반적으로 하나의 메소드를 가진 인터페이스를 구현한 익명 내부클래스로 만들어짐