4.1) 사라진 SQLEXCEPTION 초난감 예외처리 JDBC API를 쓰게 될 경우 '처리되지 않은 예외가 있다'고 예외 표시를 해준다. 이를 보고 try/catch 블록을 둘러싸주는 것으로 해결하면 컴파일러 에러 메시지도 없어지고 별문제 없이 잘 동작한다. 이때 예외가 발생하면 catch 블록을 써서 잡아내는 것까지는 좋지만 아무것도 하지 않고 별문제 없는 것처럼 넘어가 버리는 것은 정말 위험한 일이다. 결국 발생한 예외로 인해 어떤 기능이 비정상적으로 동작하거나, 메모리나 리소스가 소진되거나, 예상치 못한 문제가 일어난다. 예외가 발생하면 화면에 출력해주기는 하는 것도 다른 로그나 메시지에 금방 묻혀버리면 놓치기 쉽상이므로 콘솔 로그를 누군가가 계속 모니터링하지 않는 한 이 예외 코드는 심각한 폭..
4.0) 예외 정상적인 결과와 흐름을 보여주는 코드를 만들기도 버거운데 예외상황까지 처리해야한다는 사실이 부담스러워져 예외와 관련된 코드는 자주 엉망이 되거나 무성의하게 만들어지기 쉽다. 잘못된 예외처리 코드는 찾기 힘든 버그를 낳을 수 있고, 생각지 않았던 예외상황이 발생했을 때 상상 이상으로 난처해질 수 있다. JdbcTemplate을 대표로 하는 스프링의 데이터 액세스 기능에 담겨 있는 예외처리와 관련된 접근 방법에 대해 알아보자.
3.6) 스프링의 JDBCTEMPLATE update() 스프링이 제공하는 템플릿/콜백 기술을 살펴보자. 스프링은 JDBC를 이용하는 DAO에서 사용할 수 있도록 준비된 다양한 템플릿과 콜백을 제공한다. 거의 모든 종류의 JDBC 코드에 사용 가능한 템플릿과 콜백을 제공할 뿐만 아니라, 자주 사용되는 패턴을 가진 콜백은 다시 템플릿에 결합시켜서 간단한 메소드 호출만으로 사용이 가능하도록 만들어져 있어 템플릿/콜백 방식의 기술을 사용하고 있는지 모르고도 쓸 수 있을 정도로 편리하다. 스프링이 제공하는 JDBC 코드용 기본 템플릿은 JdbcTemplate이다. 지금까지 만들었던 JdbcContext는 버리고 스프링의 JdbcTemplate으로 바꿔보자. 현재 UserDao는 DataSource를 DI 받아서..
3.5) 템플릿과 콜백 템플릿/콜백의 동작원리 템플릿/콜백 패턴이란? 복잡하지만 바뀌지 않는 일정한 패턴을 갖는 작업 흐름이 존재하고 그중 일부만 자주 바꿔서 사용해야 하는 경우에 적합한 구조이며 전략 패턴의 기본 구조에 익명 내부 클래스를 활용한 방식이다. 전략 패턴의 컨텍스트를 템플릿이라 부르고, 익명 내부 클래스로 만들어지는 오브젝트를 콜백이라고 부른다. 템플릿은 고정된 작업 흐름을 가진 코드를 재사용한다는 의미에서 붙인 이름이며 콜백은 템플릿 안에서 호출되는 것을 목적으로 만들어진 오브젝트를 말한다. 여러 개의 메소드를 가진 일반적인 인터페이스를 사용할 수 있는 전략 패턴의 전략과 달리 템플릿/콜백 패턴의 콜백은 보통 단일 메소드 인터페이스를 사용한다. 템플릿의 작업 흐름 중 특정 기능을 위해 한..
3.4) 컨텍스트와 DI JdbcContext의 분리 전략 패턴의 구조를 살펴보자. UserDao의 메소드가 클라이언트이고, 익명 내부 클래스로 만들어지는 것이 개별적인 전략이고, jdbcContextWithStatementStrategy() 메소드는 컨텍스트다. 이 때 jdbcContextWithStatementStrategy()는 JDBC의 일반적인 작업 흐름을 담고 있으므로 다른 DAO에서도 사용 가능하다. 그러므로 UserDao 클래스 밖으로 독립시켜서 모든 DAO가 사용할 수 있게 해보자. JdbcContext 클래스로 분리해보자. JdbcContext에 UserDao에 있는 컨텍스트 메소드를 workWithStatementStrategy()라는 이름으로 옮겨놓는다. 이렇게 하면 DB 커넥션을 ..
3.3) JDBC 전략 패턴의 최적화 전략 클래스의 추가 정보 전략 패턴을 사용해 메소드에 담겨 있던 변하지 않는 부분, 자주 변하는 부분을 깔끔하게 분리해냈다. DAO는 전략 패턴의 클라이언트로서 컨텍스트 메소드에 적절한 전략인 바뀌는 로직을 제공해주는 방법을 사용하게 된다. 여기서 컨텍스트는 PreparedStatement를 실행하는 JDBC의 작업 흐름이고, 전략은 PreparedStatement를 생성하는 것이다. add() 메소드에도 적용해보자. add() 메소드에서 변하는 부분인 PreparedStatement를 만드는 코드를 AddStatement 클래스로 옮겨담아 클래스를 분리할 경우에는 deleteAll()과 달리 PreparedStatement를 만들 때 uesr라는 부가적인 정보가 필..
3.2) 변하는 것과 변하지 않는 것 JDBC try/catch/finally 코드의 문제점 UserDao의 코드를 훑어보면 복잡한 try/catch/finally 블록이 2중으로 중첩까지 되어 나오며 모든 메소드마다 반복된다. 이런 코드를 작성할 때 사용할 수 있는 가장 효과적인 방법은 복사해서 붙이기, 일명 Copy&Paste 신공이다. 그런데, 그렇게 속도를 내서 작업하다가 어느 순간 한 줄을 빼먹고 복사했거나, 몇 줄을 잘못 삭제했다면 어떻게 될까? 괄호를 잘못 닫은 게 아니라면 당장에 컴파일 에러가 나지는 않을 것이지만 해당 메소드가 호출되고 나면 커넥션이 하나씩 반환되지 않고 쌓여가게 되므로 서버에 배치해서 사용하면 언젠가 DB 풀에 설정해놓은 최대 DB 커넥션 개수를 넘어설 것이고, 서버에서..
3.1) 다시 보는 초난감 DAO 예외처리 기능을 갖춘 DAO UserDao에는 예외상황에 대한 처리에 대한 심각한 문제점이 남아있다. DB 커넥션이라는 제한적인 리소스를 공유해 사용하는 서버에서 동작하는 JDBC 코드에는 예외처리를 반드시 지켜야 한다. 정상적인 JDBC 코드의 흐름을 따르지 않고 중간에 어떤 이유로든 예외가 발생했을 경우에도 사용한 리소스를 반드시 반환하도록 만들어야만 시스템에 심각한 문제를 일으키지 않기 때문이다. UserDao의 수정 기능을 하는 deleteAll() 메소드를 살펴보자. 이 메소드에서는 Connection과 PreparedStatement라는 두 개의 공유 리소스를 가져와서 사용하고 정상적으로 처리될 경우 메소드를 마치기 전에 각각 close()를 호출해 리소스를 ..
