본문 바로가기

스프링

[spring] spring ioc_DI

1.Commons-logging : Spring-context 사용

2. Mysql-connector : Mysql JDBC

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

4. Spring-bean : 스프링 코어와 함께 의존성 주입 제공 (Core Container)

5. Spring-context : 스프링 코어, BeanFactory 확장한 어플리케이션 컨텍스트 구현, 리소스 로드 국제화 지원(Core Container)

6. Spring-core : 다른 스프링 모듈이 사용하는 유틸리티(Core Container)

7. Spring-expression : EL 확장 Bean속성(배열, 컬렉션 포함).(Core Container)

 

 

Interface를 활용하여 다형성, 어떤 커넥션 객체를 각 Dao에서 모르게 투명성 Dao에서 어떤 커넥션 객체를 사용할 지 모르므로 Dao는 수정할 필요가 없어짐

 

 

UserDao는 어떤 커넥션 객체를 받을 지 모름 사용자에게 위임 > IOC 제어역전 사용자가 객체생성을 주도함

* 인터페이스에만 의존 : 해당 객체는 런타임시점에 DI(의존성 주입) 싱글톤 방식으로. 문제가 많은 private 싱글톤 방식이 아닌 어플리케이션 컨텍스트에 의해 평범한 객체를 싱글톤 방식으로 생성함.

* DI에서 말하는 주입은 interface타입의 파라미터를 통해 객체 주입이 이루어져야 한다.

 

DaoFactory를 통해 어플리케이션 컨텍스트를 만든 예제

만약 로컬DB 혹은 타사의 커넥션을 맺어야하는 것으로 수정되야한다고 보면 위처럼 딱 한 줄 수정해주고 해당 클래스를 생성하면 된다. 만약 초난감 DAO였다고 생각해보면 모든 DAO 클래스를 전부 수정해야한다.

 

*DI의 필요성(DI로 등록하는가?) : 주입받는 오브젝트(UserDao), 주입하는 오브젝트(DConnectionMaker) 양쪽 모두 Factory에 등록되어야함. 015.템플릿,클래스분리편 참조

 

14. ApplicationContext : (=DaoFactory) 어플리케이션 모든 구성요소를 제어 작업을 담당(객체 생성과 관리 및 인터셉트 전,후처리 등).

14. AnnotationConfigApplicationContext : @Configuration이 붙은 자바코드를 설정 정보로 사용함

15. getBean(“메서드명”, 리턴타입) : 오브젝트를 요청하는 메서드. 즉 메서드의 이름이 빈의 이름이 된다. 리턴타입을 생략해도 되지만 지저분한 캐스팅 코드를 사용하지 않아도 됨.

 

* DaoFactoryApplicationContext의 차이

1.     DaoFactory

-       DAO오브젝트를 생성하고 DB생성 오브젝트와 관계를 맺어주는 제한적인 역할  

-       클라이언트는 Factory가 늘어나면 그것을 직접 선언을 해야함.

2.     ApplicationContext

-       관리할 모든 오브젝트에 대한 생성과 관계설정을 담당함.

-       오브젝트를 생성하고 관계를 맺어주는 코드가 없고, 설정정보를 통해 관계설정

-       DaoFactory 클래스 설정정보를 등록하고 @Bean이 붙은 메소드의 이름을 가져와 빈 목록을 만들어둠

-       Factory가 아무리 많아져도 이를 알아야하거나 직접 사용할 필요가 없다.

만들어지는 시점 방식,. 자동생성, 후처리, 인터셉팅 등 오브젝트를 효과적으로 사용할 수 있다.

 

만약 DB접속시 카운팅하는 로직이 추가되어야한다고 생각해보자

 

 

 

모든 DAOCount시키는 로직을 넣어야 하는 것인가??

1.     ConnectionMaker 인터페이스를 구현했지만 내부에서 직접 DB커넥션을 만들지 않고, DAODB커넥션을 가져올 때마다 호출하는 makeConnection() 에서 DB연결횟수 카운터를 증가시킨다.

15. DConnection을 사용하면서 카운터를 늘려주는 클래스를 생성

 

14. 모든 DAOconnectionMaker에서 만들어지는 오브젝트를 DI받는다.

18. DConnectionMaker 오브젝트대신 CountingConnectionMaker 오브젝트로 바꿔치기로 인해 커넥션을 가져오려고 할 때마다 카운터는 증가하고 커넥션을 그대로 맺어진다.

 

지금은 DAO가 하나뿐이지만 수십 수백개의 Dao가 사용된다해도 카운팅이 이루어진다.

다시 카운팅하는게 필요없다고 생각해보면 CountingDaoFactory 설정 클래스를 DaoFactory로 변경하거나 connectionMaker() 메소드를 수정하는 것만으로 이전상태로 복구된다.