7.1 SQL과 DAO의 분리

SQL 변경이 필요한 상황이 발생하면 SQL을 담고있는 DAO코드 수정이 필요함. → DAO와 SQL 분리 필요

7.1.1 두가지 분리방법

1. XML 설정을 이용한 분리

• SQL을 설정파일에 프로퍼티값으로 정의해서 DAO에 주입 가능
• 개별 SLQ 프로퍼티 방식
  1. add() 메소드에서 사용할 SQL을 프로퍼티로 정의
  2. 외부로부터 DI받은 SQL 문장을 담은 sqlAdd 사용
  3. XML설정의 userDao 빈에 SQL이 추가된 sqlAdd 프로퍼티 추가
• 단점 - SQL이 변경돌때마다 DAO에 프로퍼티를 추가하고 DI를 위한 변수와 수정자 메소드 생성이 필요

1. SQL맵 프로퍼티 방식

• SQL을 하나의 컬렉션으로 담아두는 방식

• 맵을 사용해 키값을 이용해 SQL문장을 가져오는 방식

  1. Map 타입의 SQLMap 프로퍼티 추가

  2. 각 메소드를 정해진 키값을 이용해 sqlMap으로부터 SQL을 가져와 사용하도록 만들기

  3. XML설정 수정

     <aside> 💡 Map을 초기화해서 sqlMap 프로퍼티에 넣기위해 <map>과 <entry>태그를 <property>태그 내부에 넣어주면 <entry>태그에 선언된 키와 값을 담은 Map 타입 오브젝트가 만들어져 프로퍼티에 주입

     </aside>

• 장점 - SQL변경 시 설정에 <entry>만 추가해주면 됨

• 단점 - 오타가 있어도 메소드 실행 전 오류 확인 불가

7.1.2 SQL 제공 서비스

• 스프링 설정파일 내에 SQL을 두고 이를 DI해서 DAO가 사용하면?
  • 손쉽게 SQL을 코드에서 분리해 낼 수 있다.
  • SQL과 DI 설정정보가 섞여 있을 경우 가독성이 떨어지며 관리가 어렵다.
  • SQL은 데이터 엑세스 로직인데 애플리케이션의 구성정보를 가진 설정정보와 함께 두는것은 좋지 않다.
  • 스프링 설정파일로부터 생성된 오브젝트와 정보는 애플리케이션을 다시 시작하기 전에는 변경이 어렵다.
  • 운영중인 애플리케이션에서 빈번하게 참조되는 맵 내용을 수정할 경우 동시성 문제를 일으킬 수 있다.

→ 결론! 독립적인 SQL 제공서비스가 필요하다!!

• SQL 서비스 인터페이스

  1. DAO의 독립적인 구현을 위해 인터페이스를 사용하고, DI로 구현 클래스의 오브젝트 주입(SQL 가져오기 실패 시 예외를 던지도록 구현)
  2. 예외의 원인메세지와 예외를 담을 수 있는 sqlRetrievalFailureException클래스 정의
  3. UserDaoJdbc가 sqlService 인터페이스를 통해 필요한 SQL을 가져올 수 있도록 만들기
  4. 모든 메소드에서 인스턴스 변수인 sqlService를 이용해 SQL을 가져올 수 있도록 수정(sqlService는 모든 DAP에서 서비스빈을 사용하도록 만들어지므로 키 이름이 DAO별로 중복되지 않도록 주의)
  5. UserDao가 SqlService 타입의 구현클래스로 정의된 빈을 DI받도록 설정 변경

• 스프링 설정을 사용하는 단순 SQL 서비스

  SQLService 인터페이스는 DAO가 요구하는 SQL을 반환하기만 하면 됨.

  1. SimpleSqlService 클래스를 빈으로 등록
  2. UserDao가 DI 받아 사용하도록 설정
  3. SQL정보를 SimpleSqlService 프로퍼티에 <map>을 이용해 등록한다.