DataAccessException

• JDBC 의 SQLException 을 전환하는 용도로만 만들어진 건 아니다.
  • 그 외 자바 데이터 액세스 기술에서 발생하는 예외에도 적용
• 의미가 같은 예외라면 데이터 액세스 기술 종류와 상관 없이 일관된 예외가 발생하도록 만든다.
  • 데이터 액세스 기술에 독립적인 추상화된 예외 제공

데이터 액세스를 위한 표준 기술

• JDBC 외에도 몇개 더 있음
• JDO 나 JPA 는 JDBC 와 마찬가지로 자바의 표준 퍼시스턴스 기술
  • JDBC 와 성격과 사용방법이 크게 다르다
  • 오라클의 TopLink 같은 상용제품이나 오픈소스인 하이버네이트 표준을 따르긴 함
  • 독자적인 프로그래밍 모델을 지원하는 ORM 기술도 있다
• iBatis
  • JDBC 를 기반으로 성격도 비슷하지만 사용 방법과 API, 발생하는 예외가 다르다.

<aside> ☝🏻

스프링은 왜 기술에 독립적인 예외를 정의하고 사용하게 하는걸까.

</aside>

DAO 인터페이스와 구현의 분리

DAO 분리하기

• 분리하는 이유 :
  1. 데이터 액세스 로직을 담은 코드를 성격이 다른 코드에서 분리
  2. 분리된 DAO 는 전략 패턴을 적용해 구현 방법을 변경해서 사용할 수 있음
  3. DAO 를 사용하는 쪽은 DAO 내부에서 어떤 데이터 액세스 기술을 사용하는지 신경쓰지 않아도 된다.
• 인터페이스를 사용해 구체적인 클래스 정보와 구현 방법을 감추고 DI 를 통해 제공되도록 하자. (전략패턴 + DI)
  • 사용 기술과 구현 코드를 클라이언트에게 감춘다.
  • 하지만 메서드 선언에 나타나는 예외 정보가 문제될 수 있다.

기술에 독립적인 이상적인 DAO 인터페이스

• 하지만 사용될 수 없다.
• 왜?
  • 데이터 엑세스 기술의 API 가 예외를 던진다.

데이터 액세스 기술에서 발생한 예외

public interface UserDao{
	public void add(User user);
	...
}

• UserDao 구현 클래스의 add() 메서드라면 SQLException 을 던질 것
• 메서드 선언에 없는 예외를 구현클래스의 메소드에 throws 에 넣을 수 없다.
  • 이를 방지하기 위해 인터페이스에 선언되어야 하는 형식
  • public void add(User user) throws SQLException;