7장) 7.6 스프링 3.1의 DI

7장 스프링 핵심 기술의 응용

7.6 스프링 3.1의 DI

• 자바 언어의 변화와 스프링
  • DI가 적용된 코드를 작성할 때 사용하는 핵심 도구인 자바 언어의 대표적인 두 가지 변화
    • 애노테이션의 메타정보 활용
    • 정책과 관례를 이용한 프로그래밍
  • 애노테이션의 메타정보 활용
    • 자바 코드의 메타정보를 이용한 프로그래밍
    • 자바 코드의 일부를 리플렉션 API 등을 이용해 어떻게 만들었는지 보고 그에 따라 동작하는 기능이 점점 많이 사용됨
    • 리플렉션 API
      • 초기 버전부터 class, interface, field, method 등의 메타정보를 살펴보거나 조작하기 위해 사용
      • 최근에는 자바 코드의 메타정보를 데이터로 활용하는 스타일의 프로그래밍 방식에 더 많이 활용
        • 애노테이션이 정점
    • 애노테이션
      • 자바 코드가 실행되는 데 직접 참여 X
      • 복잡한 리플렉션 API로 애노테이션 메타정보 조회, 애노테이션 내 설정 값을 가져와 참고하는 방법이 전부
      • 활용이 늘어난 이유
        • Application 핵심 로직을 담은 자바 코드
          이를 지원하는 IoC 방식의 프레임워크
          프레임워크가 참조하는 메타정보
          위의 세 가지로 구성하는 방식에 잘 어울리고 유리한 점이 많기 때문
  • 앞선 학습 사항
    • UserDao에 객체지향 프로그래밍의 특징을 최대한 적용하며 유연하게 확장 가능한 코드로 다듬음
      • 서로 영향을 주지 않고 확장 가능한 핵심 로직 코드
        핵심 코드가 런타임 시 동적으로 관계를 맺고 동작하게 하는 DaoFactory
        DaoFactory를 활용해 핵심 로직 코드가 관계를 맺고 동작하는 과정을 제어하는 클라이언트
        세 가지로 구분됨
      • 클라이언트는 일종의 IoC 프레임워크, DaoFactory는 IoC 프레임워크가 참고하는 일종의 메타정보로 의미가 있음
    • XML로의 전환
      • UserDao 한 가지가 아닌 애플리케이션을 구성하는 오브젝트 관계를 IoC/DI를 통해 프레임워크와 메타정보를 활용하는 방식으로 작성하도록 발전시키려면, 자바 코드로 만들어진 관계 설정 책임을 담은 코드가 불편
    • 애노테이션 적용
      • 여타 외부 파일과 달리 자바 코드의 일부로 사용
      • 코드의 동작에 직접 영향 X, 메타정보로 활용되는 데 XML에 비해 유리함
        • 정의에 따라 타입, 필드, 메소드, 파라미터, 생성자, 로컬 변수의 한 군데 이상 적용 가능하며, 메타정보를 얻을 수 있음
        • 리팩토링에 유리
          • 클래스의 패키지를 변경하거나 클래스 이름을 바꾸는 경우, 해당 클래스를 참조하는 코드도 자동으로 바꿔줌 <-> XML을 매번 수정
      • 단점
        • 자바 코드에 존재
          • 변경할 때마다 클래스를 새로 컴파일해줘야함
      • 스프링 3.1부터 애노테이션을 이용한 메타정보 작성 방식으로 거의 모든 영역이 확대됐고, 애노테이션을 활용한 프로그래밍이 성행
  • 정책과 관례를 이용한 프로그래밍
    • XML
      • 미리 정의한 정책으로 특정 기능이 동작하게 만듦
      • 자바 코드로 모든 작업 과정을 직접 표현할 때보다 작성할 내용이 줄어듦
      • 프로그래밍 언어나 API 사용법 외에 미리 정의된 많은 규칙과 관례를 기억해야 하고, 메타정보를 보고 프로그램이 어떻게 동작하는지 이해하는 등 학습 비용의 높음과 찾기 힘든 버그 양산 가능성이 높음
    • 애노테이션과 같은 메타정보를 활용하는 프로그래밍 방식
      • 코드를 이용해 명시적으로 동작 내용을 기술하는 대신, 코드 없이도 미리 약속한 규칙 or 관례를 따라 프로그램이 동작하도록 만드는 프로그래밍 스타일을 적극적으로 포용
      • 작성하는 코드 양에 비해 부가 정보가 많고, 일정한 패턴을 따르는 경우 관례를 부여해 명시적 설정을 최대한 배제 ~> 코드가 간략
      • @Transactional 대체 정책 예시
        • 중첩된 설정이 있는 경우 적용 우선순위를 직접 지명 ((order=1))
        • 충돌을 방지하기 위해 4단계의 우선순위를 가진 대체 정책을 정해둠
          • 관례를 직접 사용해야하는데, 잘못 기억하고 있는 경우 의도한 대로 동작하지 않을 수 있고 디버깅에 어려움
• 앞서 발전시켜왔던 사용자 DAO, 서비스 기능의 예제 코드를 스프링 3.1 DI 스타일로 수정해보자

7.6.1 자바 코드를 이용한 빈 설정

• 자바 코드를 이용한 빈 설정
  • XML 제거 ~> 애노테이션 으로 수정
  • Test 코드 수정하기
    • 자바 코드 기능을 테스트하는 UserTest 제외
    • UserDaoTest, UserServiceTest 수정
• 테스트 컨텍스트 변경

  • @RunWith(SpringJunit4ClassRunner.class)
    @ContextConfiguration(locations="/test-applicationContext.xml")
    public class UserDaoTest {}
    
    @RunWith(SpringJunit4ClassRunner.class)
    @ContextConfiguration(classes=TestApplicationContext.class)
    public class UserDaoTest {}

    • xml파일 참조에서 클래스 기반 참조로 수정

  • @Configuration
    @ImportResource("/test-applicationContext.xml")
    public class TestApplicationContext{}

    • DI 정보로 사용될 클래스 생성
    • 바로 XML을 제거하면 부담스러울 수 있기 때문에, @ImportResource를 통해 주입하여 단계적으로 제거
• <context:anotation-config /> 제거
  • <context:annotation-config>에 의해 등록되는 빈 후처리기가 @PostConstruct와 같은 표준 애노테이션을 인식해서 자동으로 메소드를 수정해줌
    • 하지만, 이제 컨테이너가 참고하는 DI 정보 위치가 TestApplicationContext로 바뀌었으므로 불필요
    • 컨테이너가 직접 @PostConstruct 애노테이션을 처리하는 빈 후처리기를 등록해줌
• <bean>의 전환
  • <bean>으로 정의된 DI 정보는 자바코드의 @Bean이 붙은 메소드로 거의 1:1 매칭

  • @Bean
    public DataSource dataSource() {
        SimpleDriverDataSource dataSource = new SimpleDataSource();
    
        dataSource.setDriverClass(Driver.class);
        dataSource.setUrl("jdbc:mysql://url~~");
        dataSource.setUsername("spring");
        dataSource.setPassword("book");
    
        return dataSource;
    }

    • dataSource 빈은 UserDao 등에서 DataSource 타입의 프로퍼티를 통해 주입 받아 사용
    • SimpleDriverDataSource 클래스는 DataSource의 한 가지 구현일 뿐
      • DI 원리에 따라 빈의 구현 클래스는 자유롭게 변경 가능
      • 하지만, dataSource() 메소드의 리턴 값을 SimpleDriverDataSource으로 하면, 참조하는 쪽에서 SimpleDriverDataSource 타입으로 주입 받을 위험이 있음
        • 빈 의존관계가 바뀌면 참조하는 다른 빈의 코드도 변경해야함
        • DataSource 인터페이스를 통해 안전하게 관계를 맺도록 설정

  • @Bean
    public PlatformTransactionManager transactionManager() {
        DataSourceTransactionManager tm = new DataSourceTransactionManager();
        tm.setDataSource(dataSource());
        return tm;
    }

    • dataSource 빈을 참조해서 transactionManager의 프로퍼티에 주입
    • 위와 동일한 이유로 PlatformTransactionManager 인터페이스로 느슨하고 안전하게 관계를 맺음

  • //@Autowired SqlService sqlService; // 필드 주입은 권장되지 않음
    @RequiredArgsConstructor
    private final SqlService sqlService; // final로 생성자 주입이 권장됨
    
    @Bean
    public UserDao userDao() {
        UserDaoJdbc dao = new UserDaoJdbc();
        dao.setDataSource(dataSource());
        dao.setSqlSErvice(sqlService());
        return dao;
    }
    
    @Bean
    public UserService userService() {
        UserServiceImpl service = new UserServiceImpl();
        service.setUserDao(userDao());
        service.setMailSender(mailSender());
        return service;
    }
    
    @Bean
    public UserService testUserServive() {
        TestUserService testService = new TestUserService();
        testService.setUserDao(userDao());
        testService.setMailSender(mailSender());
        return testService;
    }
    
    @Bean
    public MailSender mailSender() {
        return new DummyMailSender();
    }

    • testUserService를 XML에서 userService와 프로퍼티 정의 부분이 동일해서 parent 정의를 사용하여 상속했는데, 프로퍼티 값을 모두 직접 넣어줘야함
    • TestUserService 클래스는 public 접근 제한자로 설정하여 패키지가 달라도 접근할 수 있게 수정해줘야 함
      • public static class TestUserService extends UserServiceImpl
      • 기존에는 UserServiceTest의 내부 스태틱 멤버 클래스로 정의했었음
    • XML에서 정의한 빈을 자바에서 참조하기 위해 @Autowired를 사용
      • 권장되지 않음

  • @Bean
    public SqlService sqlService() {
        OxmSqlService sqlService = new OxmSqlService();
        sqlService.setUnmarshaller(unmarshaller());
        sqlService.setSqlRegistry(sqlRegistry());
        return sqlservice;
    }
    
    @Resource Database embeddedDatabase;
    
    @Bean
    public SqlRegistry sqlRegistry() {
        EmbeddedSqlRegistry sqlRegistry = new EmbeddedSqlRegistry();
        sqlRegistry.setDataSource(this.embeddedDatabase);
        return sqlRegistry;
    }
    
    @Bean
    public Unmarshaller unmarshaller() {
        Jax2Marshaller marshaller = new Jaxb2Marshaller();
        marshaller.setContextPath("springbook.user.sqlservice.jaxb");
        return marshaller;
    }

    • embeddedDatabase 빈은 자바 코드로 변환하지 않았으니 @Resource를 통해 필드로 주입받아 사용
    • @Autowired vs @Resource
      • Autowired
        • 필드의 타입을 기준으로 빈을 탐색
      • Resource
        • 필드의 이름을 기준으로 탐색
    • TestApplicationContext에 DataSource 타입의 dataSource 빈이 존재하므로 @Resource를 사용
• 전용 태그 전환
  • <jdbc:embedded-database>, <jdbc:script>
    • <jdbc:embedded-database>는 내장형 DB를 생성
    • <jdbc:script>는 스크립트로 초기화한 뒤, DataSource 타입 DB의 커넥션 오브젝트를 빈으로 등록

  • @Bean
    public DataSource embeddedDatabase() {
        return new EmbeddedDatabaseBuilder()
            .setName("embeddedDatabase")
            .setType(HSQL)
            .addScript("classpath:springbook/user/.../~.sql")
            .build();
    }

    • EmbeddedDatabaseBuilder를 통해 내장형 DB 종류와 초기화 스크립트를 지정하면, 위의 과정을 모두 진행
  • 앞선 코드에서 @Resource를 제거하고 sqlRegistry 빈에 프로퍼티를 embeddedDatabase 빈을 사용하도록 수정

    • @Bean
      public SqlRegistry sqlRegistry() {
          EmbeddedSqlRegistry sqlRegistry = new EmbeddedSqlRegistry();
          sqlRegistry.setDataSource(embeddedDatabase());
          return sqlRegistry;
      }

  • <tx:annotation-driven /> 태그 제거
    • 트랜잭션 AOP를 적용하려면 복잡하고 많은 빈이 동원됨
      • 어드바이스와 포인트컷
      • 애노테이션 정보에서 트랜잭션 속성을 가져와 어드바이스에서 사용하게 해주는 기능
      • 전용 태그를 사용하면 4가지 클래스를 빈으로 등록해줌
        • org.springframwork.aop.autoproxy.InfrastructureAdvisorAutoProxyCreator
        • org.springframwork.transaction.annotation.AnnotationTransactionAttributeSource
        • org.springframwork.transaction.interceptor.TransactionInterceptor
        • org.springframwork.transaction.interceptor.BeanFactoryTransactionAttributeSourceAdvisor
    • 스프링 3.1부터는 @EnableTransactionManagement 애노테이션을 사용해 위의 모든 것을 해결

    • @Configuration
      @EnableTransactionManagement
      public class TestApplicationContext {
          /*
           * DB 연결 및 트랜잭션
           */
      
          /*
           * 위에서 예시로 적었던 모든 빈 설정들
           */
      }

• XML 설정을 1:1로 자바 코드로 전환하는 작업을 진행
  • 장점은 아직 보이지 않지만, 다듬어가면서 장점을 학습하자

7.6.2 빈 스캐닝과 자동와이어링

• @Autowired를 이용한 자동와이어링
  • UserServiceImpl과 UserDaoJdbc 클래스에 @Autowired 적용
    • @Autowired는 자동와이어링 기법을 이용해서 조건에 맞는 빈을 찾아 자동으로 수정자 메소드나 필드에 주입
      • 주입 가능한 타입의 빈이 하나라면 스프링이 수정자 메소드를 호출해서 주입
      • 두 개 이상이라면 그 중 프로퍼티와 동일한 이름의 빈이 있는지 찾아 주입
      • 최종 후보를 찾지 못한 경우에 에러
    • UserDao 빈의 구현 클래스인 UserDaoJdbc는 dataSource와 sqlService 두 개의 빈에 의존
    • dataSource 설정과 sqlService 프로퍼티에 @Autowired 적용

      • public class UserDaoJdbc implements UserDao {
            @Autowired
            public void setDataSource(DataSource dataSource) {
                this.jdbcTemplate = new JdbcTemplate(dataSource);
            }
        
            @Autowired
            private SqlService sqlService;
        
            public void setSqlService(SqlService sqlService) {
                this.sqlService = sqlService;
            }
        }

        • 메소드에 @Autowired를 붙여 dataSource를 자동으로 주입
        • DataSource 타입의 빈은 userDao가 사용하는 dataSource 빈, SQL 서비스용인 embeddedDatabase 빈 두 개
          • dataSource 빈이 수정자 메소드와 이름이 동일하므로 dataSource를 주입
        • sqlService가 자동 와이어링을 통해 주입되므로, 기존 userDao 빈의 userDao() 메소드는 빈 인스턴스만 생성하도록 수정하고, 기존에 Autowired로 SqlService를 주입하던 코드를 제거
        • @Autowired SqlService sqlService

        • @Bean
          public UserDao userDao() {
              return new UserDaoJdbc();
          }

  • 자바는 private 필드에 클래스 외부에서 값을 넣을 수 없게 되어있지만, 스프링은 리플렉션 API를 통해 제약조건을 우회해서 값을 주입
  • 수정자 메소드는 없어도 되지만, 다른 오브젝트를 주입해서 테스트해야하는 경우 수정자 메소드가 필요
  • @Autowired 같은 자동와이어링은 적절히 사용하면 DI 관련 코드를 대폭 감소시켜 편리하지만, 빈 설정정보를 보고 다른 빈과 의존관계가 어떻게 맺어져있는지 한눈에 파악하기 힘듦
• @Component를 이용한 자동 빈 등록
  • @Component
    • 클래스에 부여하여 빈 스캐너를 통해 자동으로 빈 등록
      • @Component 나 이를 메타 애노테이션으로 갖고 있는 애노테이션이 붙은 클래스가 자동 빈 등록 대상
  • TestApplicationContext에 userDao() 메소드 제거, @Autowired 적용하기

    • @Autowired UserDao userDao;
      
      @Bean
      public UserService userService() {
          UserServiceImpl service = new UserServiceImpl();
          service.setUserDao(this.userDao);
          service.setMailSender(mailSender());
          return service;
      }
      
      @Bean
      public UserService testUserService() {
          TestUserService testService = new TestUserService();
          testService.setUserDao(this.userDao);
          testService.setMailSender(mailSender());
          return testService;
      }

    • userDao() 삭제 후, userDao 빈이 등록될 방법이 없어서 테스트에 실패
  • UserDaoJdbc 클래스에 @Component 추가

    • @Component
      public class UserDaoJdbc implements UserDao {}

      • 자동 빈 등록 대상임을 명시
  • TestApplicationContext에 @ComponentScan 적용

    • @Configuration
      @EnableTransactionManagement
      @ComponentScan(basePackages="springbook.user")
      public class TestApplicationContext {}

    • @Component 애노테이션이 달린 클래스를 스캔할 때, 프로젝트 내의 모든 클래스패스를 다 찾는 것은 부담이 큼
      • 특정 패키지 아래서만 찾도록 @ComponentScan을 부여
  • 위의 과정을 거쳐 다시 테스트가 통과되는데, 빈의 아이디가 userDaoJdbc로 바뀌었는데 왜 성공할까??
    • 빈을 참조하는 테스트인 UserServiceTest나 DI 설정 클래스인 TestApplicationContext에서 모두 @Autowired를 이용해 빈을 주입받기 때문
    • 아이디를 기준으로 주입할 빈을 찾지 않고 UserDao라는 타입으로 빈을 찾기 때문
    • @Component가 붙은 클래스 이름을 다른 빈 아이디로 사용하고 싶은 경우, 애노테이션 이름을 부여
      • ex) Component("userDao")
  • 메타 애노테이션
    • 애노테이션 정의에 부여된 애노테이션
      • 여러 개의 애노테이션에 공통적인 속성을 부여하려면 메타 애노테이션을 이용
    • 스프링은 @Component 외의 애노테이션으로 자동 빈 등록이 가능
      • 빈 스캔 검색 대상으로 만드는 것 외에 부가적인 용도의 마커로 사용하기 위함
      • @Transactional이 대표적인 예시
    • 애노테이션이 빈 스캔을 통해 자동등록 대상으로 인식되게 하려면 애노테이션 정의에 @Component를 메타 애노테이션을 붙여주면 됨

      • @Component
        public @interface SnsConnector {}

      • @SnsConnector
        public class FacebookConnector {}

        • @SnsConnector 애노테이션을 부여하면, 자동 빈 등록 대상으로 만들고 Sns 커넥션과 관련된 부가 정보를 함께 담을 수 있음
    • DAO 빈은 @Repository를 사용하는 것을 권장하는데, @Component를 메타 애노테이션으로 가지고 있음
      • 앞서 작성한 UserDaoJdbc 코드도 @Component에서 @Repository로 수정
  • 자동 빈 등록을 적용하는게 좋은 빈과 그렇지 않은 빈이 존재하기 때문에, 적절한 판단이 필요
  • UserServiceImpl에 @Component와 @Autowired적용하기

    • @Service("userService")
      public class UserServiceImpl implements UserService {
          ...
          @Autowired
          private UserDao userDao;
      
          @Autowired
          private MailSender mailSender;
      }

      • 빈 자동등록을 했으니 TestApplicationContext의 userService() 메소드를 제거하는게 맞는데, 문제가 생김
        • UserService 타입의 빈이 userServiceImpl과 testUserService 두 개가 존재하기 때문인데, 주입할 빈을 결정하지 못하기 때문
        • 따라서, userService라는 아이디를 부여하여 해결
  • dataSource와 transactionManager 빈은 자동등록 기능을 적용할 수 없음
    • 스프링이 제공해주는 클래스를 사용하기 때문에 소스코드에 @Component나 @Autowired 적용 불가
    • dataSource 빈은 프로퍼티에 텍스트 값을 설정해줘야하기 때문에 더욱 불가능

7.6.3 컨텍스트 분리와 @Import

• 지금까지 작성한 정보는 테스트 DI 정보와 애플리케이션이 동작하는데 필요한 DI 정보가 혼재
  • 성격이 다른 DI 정보 분리하기
• 테스트용 컨텍스트 분리
  • testUserService 빈은 테스트에서만 사용되고, 현재 작성한 mailSender 같은 경우에는 운영 중에 사용되면 안되기 때문에 분리

  • @Configuration
    public class TestAppContext {    
        @Bean
        public UserService testUserService() {
            TestUserSerivce testService = new TestUserService();
            testService.setUserDao(this.userDao);
            testService.setMailSender(mailSender());
            return testService;
        }
    
        @Bean
        public MailSender mailSender() {
            return new DummyMailSender();
        }
    }

    • 테스트용 DI 설정 클래스인 TestAppContext를 만들어 빈 설정 애노테이션, 필드, 메소드를 옮김
      • 기존 TestApplicationContext는 ApplicationContext로 네이밍을 수정하고, 이와 혼동되지 않게 테스트용은 TestAppContext로 네이밍
    • testUserService 빈은 userDao와 mailSender 빈에 의존하는데, userDao 빈은 자동으로 등록되도록 @Repository를 적용해서 @Autowired로 빈을 주입
      • TestUserService 클래스가 UserServiceImpl을 상속했기 때문에, userDao 프로퍼티는 자동와이어링 대상
        • 따라서 프로퍼티 설정 코드와 @Autowired 필드를 제거하는 것이 더 깔끔

    • @Configuration
      public class TestAppContext {
          @Bean
          public UserService testUserService() {
              return new TestUserService();
          }
      
          @Bean
          public MailSender mailSender() {
              return new DummyMailSender();
          }
      }

  • TestUserService 클래스에 @Componnet를 붙이고 @ComponentScan을 이용해 자동 등록이 되게할 수 있지만, UserDaoServiceImpl과 UserServiceTest 등이 같은 패키지 아래 존재하므로 기준 패키지를 정하기 어려움
    • 또한, 테스트용으로 특별히 만든 빈은 설정정보에 내용이 드러나있는 것이 더 좋음
    • 운영 시스템은 AppContext만 참조, 테스트는 AppContext와 TestAppContext 두 개의 DI 정보를 함께 사용

    • @RunWith(SpringJUnit4ClassRunner.class)
      @ContextConfiguration(classes={TestAppContext.class, AppContext.class})
      public class UserDaoTest {}

• @Import
  • SQL 서비스용 빈은 독립적인 모듈로 취급
    • 다른 애플리케이션에서도 사용될 수 있고, DAO에서는 sqlService 타입의 빈을 DI 받기만 하면 되지 구체적인 구현 방법을 알 필요가 없음
    • 독립적으로 개발되거나 변경될 가능성이 높음
  • SQL 서비스와 관련된 빈 분리

    • @Configuration
      public class SqlServiceContext {
          // unmarshaller, registry를 설정하는 빈, sqlRegistry의 dataSource에 embeddedDbSqlRegistry를 설정하는 빈, unmarshaller 빈, embeddedDatabaseBuilder를 사용하는 DataSource 빈 등록 코드
      }

  • SQL 관련된 DI 설정 정보를 담은 클래스를 생성했으니, 운영용과 테스트용에 등록
    • AppContext에 포함되는 보조 설정이므로, classes에 추가하기 보다 설정정보를 @Import를 통해 AppContext에서 정보를 받아오는 것이 더 좋음

    • @Configuration
      @EnableTransactionManagement
      @ComponentScan(basePackages="springbook.user")
      @Import(SqlServiceContext.class)
      pubilc class AppContext {}

7.6.4 프로파일

• 운영용 mailsender
  • JavaMail 기반의 메일 발송용 클래스 JavaMailSenderImpl 활용

    • @Bean
      public MailSender mailSender() {
          JavaMailSenderImpl mailSender = new JavaMailSenderImpl();
          mailSender.setHost("mail.mycompany.com");
          return mailSender;
      }

  • UserServiceTest 실행 시 문제 발생
    • AppContext와 TestAppContext에 정의된 빈들이 함께 사용돼서, mailSender이 충돌
    • 빈 설정 정보를 읽는 순서에 따라 우선순위가 적용됨
• 운영환경에서 반드시 필요하지만 테스트 실행 중에는 배제돼야하는 빈 설정을 별도의 설정 클래스를 만들어 관리
  • ProductionAppContext

  • @Configuration
    public class ProductionAppContext {
        @Bean
        public MailSender mailSender() {
            JavaMailSenderImpl mailSender = new JavaMailSenderImpl();
            mailSender.setHost("localhost");
            return mailSender;
        }
    }

  • 앞서 사용한 것처럼, AppContext에서 @Import로 가져온다면, 테스트에서도 사용되는 문제가 그대로 발생
  • @Profile을 이용
• @Profile과 @ActiveProfiles
  • 설정환경에 따라 빈 구성이 달라지는 내용을 프로파일로 정의하고, 실행 시점에 어떤 프로파일 빈 설정을 사용할지 지정
  • 프로파일은 설정 클래스 단위로 지정

  • @Configuration
    @Profile("test")
    public class TestAppContext {}

  • @Configuration
    @Profile("production")
    public class ProductionAppContext {}

  • @Configuration
    @EnableTransactionManagement
    @ComponentScan(basePackages="springbook.user")
    @Import({SqlServiceContext.class, TestAppContext.class, ProductionAppContext.class}) 
    public class AppContext {}

    • AppContext나 SqlServiceContext는 default 프로파일로 취급 ~> 항상 적용
    • 위와 같이 AppContext가 다 import 하고 있으므로, UserDaoTest, UserServiceTest의 @ContextConfiguration에서 AppContext.class만 설정해주면 된다
      • @ContextConfiguration(classes=AppContext.class)
  • 위의 설정을 하고 테스트를 돌리면 mailSender 빈 충돌이 발생
    • 두 설정 클래스가 프로파일이 지정되어 있어서 현재 테스트 설정으로는 어디도 포함되지 않음
    • ActiveProfile을 통해 활성 프로파일을 설정해주자

      • @RunWith(SpringRunner.class)
        @ActiveProfiles("test")
        @ContextConfiguration(classes=AppContext.class)
        public class UserServiceTest {}

    • 애플리케이션 운영 환경은 production으로 지정해주어 사용
• 컨테이너 빈 등록 정보 확인
  • 스프링 컨테이너는 BeanFactory라는 인터페이스를 구현
  • DefaultListableBeanFactory는 BeanFactory를 구현한 클래스인데, 거의 대부분의 스프링 컨테이너가 이 클래스로 빈을 등록하고 관리
    • @Autowired로 주입받아서 빈 이름과 클래스를 확인해보면 profile별로 configuration이 적용됨을 확인
• 중첩 클래스를 이용한 프로파일 적용
  • 프로파일에 따라 분리한 설정 정보를 하나의 파일로 모으기
    • 전체 구성을 살펴보기가 번거로워짐
      • 의존관계를 맺는 빈이 더 많아지면 더욱 단점
    • 프로파일이 지정된 독립된 설정 클래스의 구조는 유지한 채 소스코드의 위치만 통합
      • 스태틱 중첩 클래스 활용

    • @Configuration
      @EnableTransactionManagement
      @ComponentScan(basePackages="springbook.user")
      @Import({SqlServiceContext.class}) 
      public class AppContext {
          ...
          @Configuration
          @Profile("test")
          public static class TestAppContext {}
      
          @Configuration
          @Profile("production")
          public static class ProductionAppContext {}
      }

      • ProductionAppContext와 TestAppContext 는 중첩 클래스로 만들었으므로 클래스 파일은 삭제
      • 중첩 클래스로 프로파일 설정 클래스를 포함했으므로, @Import에 지정하지 않아도 적용
  • 빈 설정 정보가 많으면 하나의 파일로 모았을 때 전체 구조를 파악하기 쉽지 않음
    • 현재 예시의 구조는 모으는 방법이 더욱 깔끔

7.6.5 프로퍼티 소스

• AppContext에 테스트 환경에 종속되는 dataSource의 DB 연결정보가 남아있으므로 이를 분리해보자
  • 실행 환경에 따른 설정하기
  • XML or properties 같은 텍스트 파일에 저장하는 것이 좋음
    • 빌드 작업이 따로 필요 없고 수정에 용이함
• @PropertySource

  • #database.properties 파일
    db.driverClass=com.mysql.jdbc.Driver
    db.url=jdbc:mysql://localhost/springboot?characterEncoding=UTF-8
    db.username=spring
    db.password=book

  • @Configuration
    @EnableTransactionManagement
    @ComponentScan(basePackages="springbook.user")
    @Import({SqlServiceContext.class) 
    @PropertySource("/database.properties")
    public class AppContext {}

    • properties의 내용을 가져와 DB 연결정보를 프로퍼티에 주입
      • 컨테이너가 프로퍼티 값을 가져오는 대상을 프로퍼티 소스(property source)라고 함
      • 환경 변수나 시스템 프로퍼티, 프로퍼티 파일이나 리소스 위치를 지정하는 등 다양한 프로퍼티 소스 존재
      • @PropertySource를 통해 프로퍼티 소스 등록
    • @Autowired를 통해 Environment 오브젝트를 주입받아 사용하는 방법이 예시에 있지만, Driver Class를 지정해줄 때 try - catch 블록을 활용해야하는 등 번거로움
    • PropertySourcesPlaceholderConfigurer 활용
• PropertySourcesPlaceholderConfigurer
  • @Value 애노테이션을 활용

  • @Value("${db.driverClass}") class<? extends Driver> driverClass;
    @Value("${db.url}") String url;
    @Value("${db.username}") String username;
    @Value("${db.password}") String password;

  • @Bean
    public static PropertySourcesPlaceholderConfigurer placeholderConfigurer() {
        return new PropertySourcesPlaceholderConfigurer();
    }

    • 빈 팩토리 후처리기로 사용되는 빈을 정의
    • 빈 설정 메소드는 반드시 스태틱 메소드로 선언
    • @Value로 가져온 네 개의 필드는 @PropertySource로 지정한 파일에서 가져온 프로퍼티 값이 자동으로 주입됨
  • dataSource 빈에서 값 사용하기

  • @Bean
    public DataSource dataSource() {
        SimpleDriverDataSource ds = new SimpleDriverDataSource();
        ds.setDriverClass(this.driverClass);
        ds.setUrl(this.url);
        ds.setUsername(this.username);
        ds.setPassword(this.password);
    
        return ds;    
    }

7.6.6 빈 설정의 재사용과 @Enable*

• SQL 서비스 빈은 서비스 인터페이스, 즉 API인 SqlService만 Dao 노출하면 됨
  • 나머지 구현 기술, 방법은 내부에 감추고 필요에 따라 자유롭게 변경 가능해야함
  • SQL 서비스 구현 클래스는 애플리케이션의 다른 빈에 의존하지 않아서 독립적으로 패키징해서 배포 가능
  • 이미 분리가 되어있어서 @Import(SqlServiceContext.class)를 통해 필요한 곳에서 SQL 서비스를 사용 가능
• 빈 설정자
  • SQL 서비스를 재사용 가능한 독립 모듈로 만들기 위한 해결할 문제점
    • OxmlSqlService의 내부 클래스인 OxmlSqlReader
    • sqlmap.xml 파일 위치를 지정하는 부분이 예제 코드의 UserDao 위치로 고정되어 있음
    • sqlmap 프로퍼티의 디폴트 값을 UserDao 같은 사용자 예제에 종속되지 않게 수정하기
    • private Resource sqlmap = new ClassPathResource("/sqlmap.xml");
  • default 값 이외에 빈 클래스 외부에서SQL 매핑 리소스를 설정하기

    • @Bean
      public sqlService sqlService() {
          OxmSqlService sqlService = new OxmSqlService();
          ...
          sqlService.setSqlmap(new ClassPathResource("sqlmap.xml", UserDao.class));
      
          return sqlService;
      }

    • SQL 서비스 구현 클래스 내부 의존성이 제거됐지만, UserDao.class라는 애플리케이션 종속 정보가 남아있어서, 다른 애플리케이션에서 SqlServiceContext를 수정 없이 @Import로 사용 불가
    • 의존성을 제거해서 SqlServiceContext까지 독립적인 모듈로 분리하자
      • sqlmap 리소스의 위치는 바뀔 일이 없으니 초기에 한 번만 지정하면 됨
        • 기본적인 DI 활용
        • SQL과 같이 매번 달라지는 내용은 콜백 형태로 만들어서 템플릿/콜백 패턴을 쓰지만, 위의 경우는 기본 DI가 적절

      • public interface SqlMapConfig {
            Resource getSqlMapResource();
        }

      • public class UserSqlMapConfig implements SqlMapConfig {
            @Override
            public Resource getSqlMapResource() {
                return new ClassPathResource("sqlmap.xml", UserDao.class);
            }
        }

      • @Configuration
        public class sqlServiceContext {
            @Autowired SqlMapConfig sqlMapConfig;
        
            @Bean
            public SqlService sqlService() {
                ...
                sqlService.setSqlmap(this.sqlMapConfig.getSqlMapResource());
                return sqlService;
            }
        }

      • public class AppContext {
            ...
            @Bean
            public SqlMapConfig sqlMapConfig() {
                return new UserSqlMapConfig();
            }
        }

        • SqlServiceContext가 변하지 않는 SqlMapConfig 인터페이스에만 의존하고, SqlMapConfig 구현 클래스는 빈으로 정의해 런타임 시 주입
        • SqlMapConfig를 구현한 UserSqlMapConfig 클래스를 빈으로 등록하여 AppContext에서 빈을 생성
        • SQL 매핑 파일 위치 변경에 영향을 받지 않게되면서, SqlServiceContext는 SqlMapConfig와 함께 SQL 서비스 모듈에 함께 패키징되어 수정 없이 재사용 가능
  • AppContext에서 SqlMapConfig를 직접 구현하기
    • SQL 매핑 파일 리소스 위치도 애플리케이션 빈 설정 관련 정보인데, 새로운 클래스를 추가한 것이 복잡
    • AppContext는 빈을 정의하고 DI 정보를 제공하는 설정용 클래스인 동시에 스스로도 빈이기 때문에, AppContext에서 직접 구현해도 무관
      • 컨테이너에 의해 빈 오브젝트로 만들어짐

    • public class AppContext implements sqlMapConfig {
          ...
      
          @Override
          public Resource getSqlMapResource() {
              return new ClassPathResource("sqlmap.xml", UserDao.class);
          }
      }

• @Enable* 애노테이션
  • @Import를 통해 SqlServiceContext를 사용할 수 있지만, 조금 더 직관적인 의미가 있다면 더욱 좋음
  • @Import애노테이션과 빈 설정 클래스 값을 메타 애노테이션으로 넣어 애노테이션을 생성하자

    • @Import(value=SqlServiceContext.class)
      public @interface EnableSqlService {}

  • @Import대신 @EnableSqlService로 사용하기

    • @Configuration
      @ComponentScan(basePackages="springbook.user")
      @EnableTransactionManagement
      @EnableSqlService
      @PropertySource("/database.properties")
      public class AppContext implements SqlMapConfig {}

      • SQL 서비스를 사용한다는 의미가 더욱 명확
  • 메타 애노테이션을 부여하면서 애노테이션을 만들어 사용하면, 애노테이션을 정의하면서 엘리먼트를 넣어 옵션을 지정하게 할 수도 있다
    • SQL 매핑 파일을 전달하게 했던 방식을 더욱 간결하게 만들 수 있음
    • @EnableSqlService("classpath:/springbook/user/sqlmap.xml")