토비스프링

    [토비 스프링] CH5-1. 서비스 추상화

    [토비 스프링] CH5-1. 서비스 추상화

    서비스 추상화 환경과 상황에 따라서 기술이 바뀌고, 그에 따라 다른 API를 사용하고 다른 스타일의 접근 방법을 따라야 하는 것은 피곤한 일이다. 이번 챕터에서는 지금까지 만든 DAO에 트랜잭션을 적용해보면서 스프링이 어떻게 성격이 비슷한 여러 종류의 기술을 추상화하고 이를 일관된 방법으로 사용할 수 있는지 살펴보자. 사용자 레벨 관리 기능 추가 지금까지 만들었던 UserDao는 기본적인 CRUD기능만 하고 있는데 여기에 간단한 비즈니스 로직을 추가해보자. 사용자 레벨은 BASIC, SILVER, GOLD 세 가지 중 하나다. 사용자가 처음 가입하면 BASIC 레벨이 되며, 이후 활동에 따라서 한 단계씩 업그레이드될 수 있다. 가입 후 50회 이상 로그인을 하면 BASIC에서 SILVER 레벨이 된다. ..

    [토비 스프링] CH4-2. 예외 전환

    예외 전환의 목적 예외 전환의 목적은 두 가지이다. 런타임 예외로 바꿈으로써 필요하지 않은 catch문을 줄여주기 위함 로우레벨 예외를 좀 더 의미 있고 추상화된 예외로 바꾸기 위함 JDBC의 한계 JDBC는 자바를 이용해 DB에 접근하는 방법을 추상화된 API 형태로 정의해놓고, 각 DB 업체가 JDBC 표준을 따라 만들어진 드라이버를 제공하게 해준다. 하지만 DB를 자유롭게 변경해서 사용할 수 있는 유연한 코드를 보장해주지는 못한다. 이유는 다음과 같다. 비표준 SQL 많은 DB가 표준을 따르지 않는 비표준 문법과 기능을 제공한다. 비표준 SQL은 DAO 코드에 들어가고, 해당 DAO는 특정 DB에 종속적인 코드가 되어 버린다. 이를 해결하기 위한 방법은 두 가지이다. 호환 가능한 표준 SQL만 사용..

    [토비 스프링] CH4-1. 예외처리

    [토비 스프링] CH4-1. 예외처리

    초난감 예외처리 자바를 처음 배우면 예외처리를 다음과 같이 try-catch문을 써서 처리한다. try { ... } catch(SQLException e) { } 예외가 발생하는 것을 catch블록을 써서 잡아내는 것은 좋은데 아무것도 하지 않고 별문제 없는 것처럼 넘어가 버리는 건 위험한 일이다. (리소스 소진, 예상치 못한 다른 문제를 야기한다.) 다음과 같은 코드들도 잘못 된 예외 처리 방식이다. 오류 메세지는 출력해주지만, 다른 로그나 메세지에 금방 묻혀버려 놓치기 쉽다. catch(SQLException e) { System.out.println(e); } catch(SQLException e) { System.out.println(); } 모든 예외는 적절하게 복구되든지 아니면 작업을 중단시..

    [토비 스프링] CH3-1. 초난감 DAO의 예외처리와 해결

    [토비 스프링] CH3-1. 초난감 DAO의 예외처리와 해결

    초난감 DAO의 문제점 UserDao를 많이 개선했지만 아직 예외상황에 대한 처리가 안되어 있다는 문제가 있다. UserDao에 예외처리를 할 수 있도록 기능을 추가해보자. 예외처리 기능을 갖춘 DAO JDBC는 어떤 상황에서도 가져온 리소스를 반환하도록 try/catch/finally 구문 사용을 권장하고 있다. public void deleteAll() throws SQLException { Connection c = null; PreparedStatement ps = null; try { c = dataSource.getConnection(); ps = c.prepareStatement("delete from users"); ps.executeUpdate(); } catch (SQLException..

    [토비 스프링] CH2-2. 스프링과 JUnit

    [토비 스프링] CH2-2. 스프링과 JUnit

    현재 문제점 테스트 코드가 어느 정도 깔끔해지긴 했지만 어플리케이션 컨텍스트의 생성 방식에 문제가 있다. @Before 메소드가 테스트 메소드 개수만큼 반복되기 때문에 컨텍스트도 여러 번 생성된다. 빈이 많아지고 복잡해지면 애플리케이션 컨텍스트 생성에 적지 않은 시간이 걸린다. 또 한 초기화 될 때 어떤 빈은 독자적으로 많은 리소스를 할당하거나 독립적인 스레드를 띄우기 때문에 테스트를 마칠 때마다 애플리케이션 컨텍스트 내의 빈이 할당한 리소스 등을 정리해주지 않으면 다음 컨텍스트를 만들 때 문제가 생길 수 있다. 애플리케이션 컨텍스트의 경우 초기화되고 나면 내부의 상태가 바뀌지 않기 때문에 한 번만 만들고 여러 테스트가 공유해서 사용하도록 하는 것이 좋다. 이를 위해 스프링이 직접 제공하는 애플리케이션 ..