# 7. Applications of Core Spring Technologies
## 7.1. SQL과 DAO의 분리
DAO는 원래 “테이블에서 데이터를 읽고/쓰는 작업”을 캡슐화하려고 존재합니다. 그런데 실제 코드에서는 SQL이 테이블/필드 정보를 **고스란히 포함**합니다. 이 SQL은 다음 이유로 자주 바뀝니다.
***왜 SQL을 DAO에서 분리해야 하는가***
* ***DB 구조 변경의 직접 영향***\
컬럼명이 바뀌거나(예: `password` → `pwd`), 하나의 컬럼이 여러 컬럼으로 쪼개지거나, 반대로 합쳐질 수 있습니다. SQL 문자열이 DAO 코드에 들어 있으면 DAO 코드 자체가 수정 대상이 됩니다.
* ***운영 중 SQL 변경 요구***\
성능 튜닝이나 장애 대응으로 SQL을 조정해야 하는 상황이 생깁니다. 그때마다 DAO 코드를 고치고 다시 빌드/배포하는 흐름은 번거롭고 위험합니다.
* ***실수 탐지의 어려움***\
SQL은 문자열이라 “컴파일 타임 검증”이 어렵습니다. 특히 XML/문자열로 옮기면 오타가 더 늘 수 있고, 실행 전까지 확인하기가 어렵습니다. 그래서 **테스트(예: UserDaoTest)** 로 SQL 정상 동작을 조기에 검증해야 합니다.
* ***역할 분리(관심사의 분리)***\
DAO의 핵심 책임은 “어떤 SQL을 쓸지 결정”하는 것이 아니라 “필요한 데이터를 조회/갱신하는 기능 제공”입니다. SQL의 저장/관리/로딩 방식까지 DAO가 떠안으면 책임이 섞입니다.
### 7.1.1 XML 설정을 이용한 분리
가장 단순한 방법은 **SQL을 스프링 XML 설정으로 빼고, DAO는 DI로 주입받아 사용**하는 것입니다.
***개별 SQL 프로퍼티 방식***
* 각 SQL을 `sqlAdd`, `sqlGet` 같은 프로퍼티로 DAO에 주입합니다.
* SQL이 늘어날수록 프로퍼티/세터가 계속 늘어난다는 단점이 있습니다.
```kotlin
import org.springframework.jdbc.core.JdbcTemplate
import javax.sql.DataSource
class UserDaoJdbc(
dataSource: DataSource
) {
private val jdbcTemplate: JdbcTemplate = JdbcTemplate(dataSource)
// XML에서 주입받는 SQL
private var sqlAdd: String = ""
fun setSqlAdd(sqlAdd: String) {
this.sqlAdd = sqlAdd
}
fun add(user: User) {
jdbcTemplate.update(
sqlAdd,
user.id,
user.name,
user.password,
user.email,
user.level.value,
user.login,
user.recommend
)
}
}
data class User(
val id: String,
val name: String,
val password: String,
val email: String,
val level: Level,
val login: Int,
val recommend: Int
)
enum class Level(val value: Int) { BASIC(1), SILVER(2), GOLD(3) }
```
```xml
```
***SQL 맵(Map) 프로퍼티 방식***
개별 프로퍼티 방식은 SQL이 늘어날 때마다 DAO에 세터/필드가 계속 추가됩니다. 이를 줄이기 위해 SQL을 **Map으로 한 번에 주입**합니다.
* DAO는 `sqlMap["add"]` 처럼 **키로 SQL을 조회**해서 사용합니다.
* 장점: DAO 코드가 단순해지고 SQL 추가 시 DAO 변경이 줄어듭니다.
* 단점: 키 오타/누락은 실행 전 검증이 어렵습니다. 그래서 테스트가 더 중요해집니다.
```kotlin
import org.springframework.jdbc.core.JdbcTemplate
import javax.sql.DataSource
class UserDaoJdbcWithMap(
dataSource: DataSource
) {
private val jdbcTemplate: JdbcTemplate = JdbcTemplate(dataSource)
private var sqlMap: Map = emptyMap()
fun setSqlMap(sqlMap: Map) {
this.sqlMap = sqlMap
}
fun add(user: User) {
val sql = sqlMap["add"]
?: throw IllegalStateException("SQL key 'add'를 찾을 수 없습니다.")
jdbcTemplate.update(
sql,
user.id,
user.name,
user.password,
user.email,
user.level.value,
user.login,
user.recommend
)
}
}
```
```xml
```
### 7.1.2 SQL 제공 서비스
XML에서 SQL을 DI로 주입하는 방식은 가능하지만, “DAO 설정”과 “SQL 설정”이 한 파일에 섞이면 관리가 지저분해질 수 있습니다. 또한 SQL을 XML이 아닌 **다른 포맷/저장소(별도 파일, DB, 외부 서비스 등)** 에서 가져오고 싶어질 수도 있습니다.
그래서 책은 한 단계 더 나아가서, DAO가 SQL을 직접 들고 있지 않고 **SqlService라는 별도 컴포넌트에게 SQL을 요청**하도록 만듭니다.
핵심은 다음과 같습니다.
* DAO의 관점: “필요한 SQL을 키로 요청해서 받는다.”
* SqlService의 관점: “SQL을 어디서/어떻게 보관하고 로딩할지 책임진다.”
* 즉, SQL 저장/로딩 방식이 바뀌어도 **DAO는 영향을 덜 받도록** 구조를 분리합니다.
***SQL 서비스 인터페이스***
```kotlin
interface SqlService {
@Throws(SqlRetrievalFailureException::class)
fun getSql(key: String): String
}
```
***SQL 조회 실패 예외(RuntimeException)***
SQL 조회 실패는 대부분 복구가 어렵다고 보고, 책에서는 런타임 예외로 정의합니다(필요하면 원인(cause)도 담도록 생성자 2개 제공).
```kotlin
class SqlRetrievalFailureException(
message: String,
cause: Throwable? = null
) : RuntimeException(message, cause)
```
***DAO는 SqlService만 의존하도록 변경***
이제 DAO는 `sqlMap` 같은 구체 구현 대신 `sqlService.getSql("userAdd")`처럼 **서비스를 통해 SQL을 얻습니다.**\
또한 키 충돌을 피하려고 `userAdd`, `userGet`처럼 “DAO/도메인 이름을 포함한 키”를 쓰는 방향을 제시합니다.
```kotlin
import org.springframework.jdbc.core.JdbcTemplate
import org.springframework.jdbc.core.RowMapper
import javax.sql.DataSource
class UserDaoJdbcWithSqlService(
dataSource: DataSource
) {
private val jdbcTemplate: JdbcTemplate = JdbcTemplate(dataSource)
private lateinit var sqlService: SqlService
fun setSqlService(sqlService: SqlService) {
this.sqlService = sqlService
}
private val userMapper: RowMapper = RowMapper { rs, _ ->
User(
id = rs.getString("id"),
name = rs.getString("name"),
password = rs.getString("password"),
email = rs.getString("email"),
level = Level.values().first { it.value == rs.getInt("level") },
login = rs.getInt("login"),
recommend = rs.getInt("recommend")
)
}
fun add(user: User) {
jdbcTemplate.update(
sqlService.getSql("userAdd"),
user.id, user.name, user.password, user.email,
user.level.value, user.login, user.recommend
)
}
fun get(id: String): User {
return jdbcTemplate.queryForObject(
sqlService.getSql("userGet"),
userMapper,
id
)!!
}
fun getAll(): List {
return jdbcTemplate.query(
sqlService.getSql("userGetAll"),
userMapper
)
}
fun deleteAll() {
jdbcTemplate.update(sqlService.getSql("userDeleteAll"))
}
fun getCount(): Int {
return jdbcTemplate.queryForObject(
sqlService.getSql("userGetCount"),
Int::class.java
)!!
}
fun update(user: User) {
jdbcTemplate.update(
sqlService.getSql("userUpdate"),
user.name, user.password, user.email,
user.level.value, user.login, user.recommend,
user.id
)
}
}
```
***스프링 설정을 사용하는 단순 SQL 서비스(SimpleSqlService)***
가장 단순한 구현으로, `SimpleSqlService`는 내부에 `Map`을 가지고 있다가 키로 SQL을 찾아 반환합니다. 못 찾으면 `SqlRetrievalFailureException`을 던집니다.
```kotlin
class SimpleSqlService : SqlService {
private var sqlMap: Map = emptyMap()
fun setSqlMap(sqlMap: Map) {
this.sqlMap = sqlMap
}
override fun getSql(key: String): String {
val sql = sqlMap[key]
if (sql == null) {
throw SqlRetrievalFailureException("키 '$key'에 대한 SQL을 찾을 수 없습니다.")
}
return sql
}
}
```
```xml
```
***이 단계의 의미***
* XML에서 SQL을 주입하는 방식(7.1.1)은 “SQL을 코드에서 밖으로 빼는 것”이 목적이었다면,
* SQL 제공 서비스(7.1.2)는 “DAO가 SQL의 저장/로딩 방식에 대해 몰라도 되게 만드는 것”이 목적입니다.
즉, DAO는 **키만 알면 되고**, SQL을 어디에 두고 어떻게 갱신하는지는 SqlService가 책임지는 구조로 옮겨가며, 이후 더 유연한 SQL 관리(다른 저장소/동적 갱신 등)로 확장할 기반을 만듭니다.
## 7.2. 인터페이스의 분리와 자기참조 빈
* 7.2의 핵심은 **하나의 클래스에 몰려 있던 책임을 인터페이스 기준으로 분리**하는 것입니다.
* `XmlSqlService`에는 사실 두 가지 책임이 있었습니다.
1. SQL을 읽어오는 책임 (Reader)
2. SQL을 저장하고 조회하는 책임 (Registry)
* 이 두 책임을 각각 `SqlReader`, `SqlRegistry` 인터페이스로 분리하고, `SqlService`는 이 둘을 협력시키는 상위 인터페이스가 됩니다.
* 이후 하나의 클래스가 여러 인터페이스를 구현하고, 스프링 DI를 통해 **자기 자신을 주입(self reference)** 하여 협력 구조를 구성합니다.
* 마지막에는 기본 의존관계를 내부에서 생성하는 `DefaultSqlService`를 통해 **디폴트 의존관계 전략**까지 정리합니다.
`SqlService`를 도입했지만, 구현 클래스인 `XmlSqlService`는 여전히 많은 책임을 갖고 있었습니다.
* XML을 읽는다.
* JAXB로 변환한다.
* SQL을 Map에 저장한다.
* 키로 SQL을 조회한다.
이 상태는 단일 책임 원칙에 어긋날 가능성이 큽니다. 확장 포인트도 부족합니다.
### 7.2.1. XML 파일 매핑
SQL을 `