• 스프링의 모든 기술은 결국 객체지향적인 언어의 장점을 적극적으로 활용해서 코드를 작성하도록 도와주는 것
• 지금까지 살펴봤던 세 가지 기술을 애플리케이션 개발에 활용해서 새로운 기능을 만들어보고 이를 통해 스프링의 개발철학과 추구하는 가치, 스프링 사용자에게 요구되는 게 무엇인지 살펴보기

🌱 Branch chapter07/refactor7.1에 실습 적용

1. XML 설정을 이용한 분리

   • SQL을 스프링의 XML 설정 파일로 빼내는 것
   • 스프링에서는 String 값을 외부에서 DI 해서 사용할 수 있기 때문에 손쉽게 SQL 분리 가능
   • But, 매번 새로운 SQL이 필요할 때 마다 프로퍼티를 추가하고 DI를 위한 변수와 setter도 생성

2. SQL 맵 프로퍼티 방식

   • SQL을 하나의 컬렉션으로 담아두는 방법
   • 맵으로 만들어두면 새로운 SQL이 필요할 때 설정에만 추가해주면 되니 작업량이 줄고 코드 간단
   • But, 실수가 있어도 해당 메소드가 실행되기 전에는 오류를 확인하기 힘듦

   스프링의 설정파일 안에 SQL을 두고 이를 DI 해서 DAO가 사용할 때 문제점

   • SQL과 DI 설정 정보가 섞여 있으면 지저분하고 관리 힘듦
   • SQL을 꼭 스프링의 빈 설정 방법을 사용해 XML에 담아둘 필요가 없다
   • 애플리케이션을 다시 시작하기 전에는 변경이 매우 어렵다

   
   

   결론 : 독립적인 SQL 제공 서비스가 필요

   
   

3. SQL 서비스 인터페이스

   • 어떤 기술적인 조건이나 제약사항도 담겨있지않다
   • SQL서비스의 기능 : SQL에 대한 키 값을 전달하면 그에 해당하는 SQL을 돌려주는 것

   모든 DAO는 SQL을 어디에 저장해두고 가져오는지에 대해서는 전혀 신경 쓰지 않아도 된다

🌱 Branch chapter07/refactor7.2에 실습 적용 -> 실습 제외

• XML에 담긴 정보를 파일에서 읽어오는 방법으로써 가장 간단하게 사용할 수 있는 방법
• java.xml.bind 패키지 안에서 JAXB 구현 클래스를 이용
• XML 문서의 구조를 정의한 스키마를 이용해서 매핑할 오브젝트의 클래스까지 자동으로 만들어주는 컴파일러도 제공

• JAXB에서 XML 문서를 읽어서 자바의 오브젝트로 변환하는 것을 칭함

• 반대로 바인딩 오브젝트를 XML 문서로 변환하는 것을 마샬링이라고 한다

• 특정 의존 오브젝트가 대부분의 환경에서 거의 디폴트라고 해도 좋을 만큼 기본적으로 사용될 가능성이 있다면, 디폴트 의존관계를 갖는 빈을 만드는 것을 추천

• 외부에서 DI 받지 않는 경우 기본적으로 자동 적용되는 의존 관계

• 디폴트에 적용하고 싶은 의존 오브젝트를 생성자 안에 직접 만들어 스스로 DI

• 디폴트 의존관계 주의점

  • 설정을 통해 다른 구현 오브젝트를 사용하게 해도 디폴트 오브젝트 생성자에서 "일단" 디폴트 의존 오브젝트를 다 만들어버린다 (비록 바로 대체된다 하더라도!)
  • 자동 생성의 부담을 무시할 수 없다면, 디폴트 의존 오브젝트가 아예 만들어지지 않을 방법을 사용
  • ex) @PostConstructor 초기화 메소드를 이용해 프로퍼티가 설정됐는지 확인하고 없는 경우에만 디폴트 오브젝트 생성

JAXB 외에도 실전에서 자주 사용되는 XML과 자바 오브젝트 매핑 기술 : Castor, JiBX, XmlBeans, Xstream

• XML과 자바 오브젝트를 매핑해서 상호 변환해주는 기술

여러가지 종류의 리소스에 접근하는 방식을 단일 인터페이스와 메소드로 추상화

• 스프링에서는 자바에 존재하는 일관성 없는 리소스 접근 API를 추상화해서 Resource 추상화 인터페이스 정의

  • But, Resource는 스프링에서 빈이 아니라 값으로 취급

  • ResourceLoader : 문자열 안에 리소스 종류/위치를 표현하며 정의된 리소스를 실제 Resource 타입 오브젝트로 변환

    ResourceLoader가 처리하는 접두사 예

    접두어	예	설명
    file:	file:C:/temp/file.txt	파일 시스템안의 리소스에 접근
    classpath:	classpath:file.txt	클래스패스의 루트에 존재하는 리소스에 접근

| X | WEB-INF/test.dat | 접두어가 없는 경우, ResourceLoader 구현에 따라 리소스 위치 결정 | | http: | http://www.testserver.com/test.dat | HTTP 프로토콜을 사용해 접근할 수 있는 웹상의 리소스 지정 |

스프링의 애플리케이션 컨텍스트 역시 `ResourceLoader` 인터페이스 상속

• DI를 적용할 때는 가능한 한 인터페이스를 사용하게 해야한다. 클래스를 직접 사용해도 되지만, 두 개의 오브젝트가 인터페이스를 통해 느슨하게 연결돼야하기 때문

• 인터페이스를 사용하는 이유

  • 다형성 : 하나의 인터페이스를 통해 여러 개의 구현을 바꿔가면서 사용할 수 있게 하는 것

  • 인터페이스 분리 원칙을 통해 클라이언트와 의존 오브젝트 사이의 관계를 명확하게 해줄 수 있기 때문

    * 인터페이스 분리 원칙 : Interface Segregation Principle. 오브젝트 그 자체로 충분히 응집도가 높은 작은 단위로 설계됐더라도, 목적과 관심이 각기 다른 클라이언트가 있다면 인터페이스를 통해 이를 적절하게 분리해줄 필요가 있다

🌱 Branch chapter07/refactor7.5에 실습 적용

• 기존 HashMap으로는 멀티스레드 환경에서 동시에 수정을 시도하거나 수정과 동시에 요청하는 경우 예상치 못한 결과가 발생할 수 있다

• 멀티스레드 환경에서 안전하게 HashMap을 조작하려면 Collections.synchronizedMap() 등을 이용해 외부에서 동기화해줘야 함

• 그래서 동기화된 해시 데이터 조작에 최적화되도록 만들어진 ConcurrentHashMap을 사용하는 방법이 일반적으로 권장

  * ConcurrentHashMap : 데이터 조작 시 전체 데이터에 대해 락을 걸지 않고 조회는 락을 아예 사용하지 않는다. 어느 정도 안전하면서 성능이 보장되는 동기화된 HashMap으로 이용하기 적당

• ConcurrentHashMap는 저장되는 데이터의 양이 많아지고 잦은 조회&변경이 일어나는 환경에서 한계

• DB의 장점과 특징은 그대로 갖고 있으면서도 애플리케이션 외부에 별도로 설치하고 셋업하는 번거로움 없는 내장형 DB 사용

  * 내장형 DB : 애플리케이션에 내장되서 애플리케이션과 함께 시작되고 종료되는 DB

• 스프링 빈에는 팩토리 빈을 만드는 번거로운 작업을 대신해주는 전용 태그가 존재한다

  <jdbc:embedded-database id=”embeddedDatabase” type=”HSQL”>
      <jdbc:script location=”classpath:schema.sql”/>
  </jdbc:embedded-database>

• 스프링에서 트랜잭션을 적용할 때 트랜잭션 경계가 DAO 밖에 있고 범위가 넓은 경우라면 AOP를 이용하는 것이 편리하겠지만, SQL 레지스트리라는 제한된 오브젝트 내에서 서비스에 특화된 간단한 트랜잭션이 필요한 경우 간단히 트랜잭션 추상화 API를 직접 사용하는게 편리

🌱 Branch chapter07/refactor7.6에 실습 적용

• 어노테이션의 메타정보 활용

  • 자바 코드의 메타정보를 데이터로 활용하는 스타일의 프로그래밍 방식이 많이 활용되기 시작하며, 어노테이션을 적극 활용했다
  • 어노테이션 : 선언만으로 다양한 부가 정보를 알아낼 수 있으며, XML처럼 단순 텍스트로 작성된 데이터는 번거롭고 안전하지 못해서 대비됨
    • 어노테이션의 단점? 자바 코드상에 존재하므로 변경할 때마다 매번 클래스를 새로 컴파일해줘야 한다

• 정책과 관례를 이용한 프로그래밍

  • 미리 정의된 많은 규칙과 관례를 기억해야하고, 메타정보를 보고 프로그램이 어떻게 동작할지 이해해야하는 부담을 주기도 하기 때문에, 스타일의 변화

• @ContextConfiguration : 스프링 테스트가 테스트용 DI 정보를 어디서 가져와야하는지 지정할 때 사용
• @ImportResource : XML의 설정정보를 자바 클래스로 만들어진 DI 설정정보로 가져오게 할 수 있다

• <bean>으로 정의된 DI 정보 -> @Bean이 붙은 public 메소드와 거의 1:1 매핑
  • @Bean 메소드 특징
    • bean의 아이디는 메소드 이름으로 설정
    • 리턴 타입은 구현을 바꿀 수 있는 인터페이스 타입 사용
    • 프로퍼티(속성)이 없다면 오브젝트 생성과 동시에 바로 리턴 가능
    • 프로퍼티가 있는 경우, 로컬 변수(인터페이스 X, 구현체O)로 받아두어야함

• @Autowired : 필드의 타입을 기준으로 빈을 찾음
• @Resource : 필드 이름을 기준으로 빈을 찾음

• <tx:annotation-driven />으로 정의된 정보 -> @EnableTransactionManagement

• 기존의 @Autowired는 스프링 테스트 클래스나 DI 설정용 @Configuration 클래스에서 스프링 컨테이너가 생성한 빈을 클래스의 멤버 필드로 주입받기 위해 사용

• 기존에 빈의 프로퍼티에 다른 빈을 넣어서 런타임 관계를 맺어주는 방법

  • <bean>의 <property>를 사용해 정의
  • 자바 코드로 직접 수정자 메소드 호출

• @Autowired는 자동 와이어링 기법을 이용해서 조건에 맞는 빈을 찾아 자동으로 수정자 메소드나 필드에 넣어줌

  • 컨테이너가 이름/타입을 기준으로 주입될 빈을 찾아주기 때문에 빈의 프로퍼티 설정을 직접 해주는 자바 코드나 XML 양을 대폭 줄일 수 있다

  • 하지만 빈 설정정보를 보고 다른 빈과 의존관계가 어떻게 맺어져 있는지 한눈에 파악하기 힘들다

    @Autowired			// dao.setDataSource(dataSource); 없이 자동으로 빈을 찾아 주입된다
    public void setDataSource(DataSource dataSource){
        this.jdbcTemplate = new JdbcTemplate(dataSource);
    }

• @Component가 붙은 클래스는 빈 스캐너를 통해 자동으로 빈으로 등록된다
  • 빈으로 등록될 후보 클래스에 붙여주는 일종의 마커 : marker라고 보면 된다
• 프로젝트 내의 모든 클래스패스를 다 뒤져서 @Component를 찾기에는 부담이 많다 -> @ComponentScan 사용
  • @ComponentScan의 basePackages 엘리먼트 : @Component가 붙은 클래스를 스캔할 기준 패키지를 지정

* 메타 어노테이션

어노테이션의 정의에 부여된 어노테이션

여러 개의 어노테이션에 공통적인 속성을 부여할 때 메타 어노테이션을 이용

• 양쪽에 모두 필요하면서 빈의 내용이 달라져야하는 경우에 빈 설정 정보 작성이 곤란해진다
• 빈 설정정보가 달라져야 하는 경우에 파일을 여러 개로 쪼개고 조합하는 등의 번거로운 방법 대신, 간단히 설정정보를 구성할 수 있는 방법을 제공 : @Profile, @ActiveProfiles
  • 실행환경에 따라 빈 구성이 달라지는 내용을 프로파일로 정의해서 만들어두고, 실행 시점에서 어떤 프로파일의 빈 설정을 사용할지 지정