DI를 적용하게 되면 수직적인 계층구조를 갖게 된다.
1. 애플리케이션 계층
2. 추상화 계층
3. 기술 서비스 계층
이 계층에 자바파일을 대응 시켜보면 다음과 같다.
1. 서비스 로직을 구현한 클래스
2. 인터페이스 (기술들의 공통 기능을 추상화하여 메소드로 선언)
3. 인터페이스를 구현한 클래스들
눈치 챘을까? 완전히 전략 패턴이다.
이 계층 구조을 통해 DI를 설명해보자.
1. 서비스 로직을 구현한 클래스는 추상화된 2. 인터페이스를 사용함으로써 변경에는 닫혀있고 확장에는 열려있는 OCP 원칙을 따른다. 그리고 스프링 프레임워크가 DI를 통해 3. 인터페이스를 구현한 클래스들 중 전략에 맞는 클래스를 선정하여 singletone instance을 생성하여 2. 인터페이스에 대입해준다.
수직 계층구조의 예이다.
1. do Something Service
2. PlatformTransactionManager
3. DataSourceTransactionManager, JtaTransactionManager, HibernateTransactionManager
예를 하나 더 들어보자.
1. db access logic
2. DataSource
3. ComplexDataSource, SimpleDriverDataSource, BasicDataSource/ org.postgresql.Driver, com.mysql.jdbc.Driver
추상화된 인터페이스를 사용하고 스프링의 DI 에게 의존관계 설정을 떠맡기면..
개발자는 3. 기술계층이 변경된다 하더라도 1. 애플리케이션 계층을 전혀 수정하지 않아도 된다.
'아는 만큼 보인다 > Spring Framework' 카테고리의 다른 글
데코레이터 패턴 ==> 다이나믹프록시(자바) + 팩토리빈(스프링) (0) | 2012.06.13 |
---|---|
스프링이 빈 오브젝트를 생성하는 방법 (0) | 2012.06.12 |
JdbcTemplate (쓰기 편한 database 접속 api) (0) | 2012.05.23 |
DI Container = ApplicationContext의 또 다른 이름.. (0) | 2012.05.07 |
Singleton Registry = ApplicationContext의 또 다른 이름 (0) | 2012.05.04 |