빈 후처리기를 사용한 자동생성 DefaultAdvisorAutoProxyCreator transactionAdvisor 위 설정파일을 보면 이전에 ProxyFactoryBean 을 이용해서 중복코드를 많이 줄여냈지만 그래도 여전히 프록시가 필요할때마다 설정파일이 어느정도 반복되고있다. 중복을 발견했으니 또 없애보자. 스프링에서 제공하는 애플리케이션 컨텍스트에 대한 확장포인트인 BeanPostProcessor 인터페이스를 구현하면되는데 DefaultAdvisorAutoProxyCreator가 해당 인터페이스를 구현하고 있다. 빈후처리기? 빈으로 등록해두면 모든 빈들이 등록될때마다 후처리기에 넘어가서 특정 작업을 수행한다. DefaultAdvisorAutoProxyCreator 를 빈으로 등록해두면 새로 등..
6장은 양이 많아서 두번에 나눠서 정리! 프록시, 데코레이터 0. 이전코드 트랜잭션코드를 분리하고 싶은 욕구가 든다. public class UserService { public void upgradeLevels() { TransactionStatus status = this.transactionManager.getTransaction(new DefaultTransactionDefinition()); try { List users = userDao.getAll(); for (User user : users) { if (canUpgradeLevel(user)) { upgradeLevel(user); } } this.transactionManager.commit(status); } catch (Runtime..
앞쪽의 내용은 유저등급을 올리는 upgradeLevels() 메서드의 리팩터링 과정 비즈니스 로직에서의 경계설정 유저들의 등급을 올리다가 하나에 문제가 생기면 전체를 롤백해달라는 요구사항에 대응해야한다. 현재구조는 UserDao의 메서드가 사용될때마다 JdbcTemplate에 의해 트랜잭션이 생겼다 커밋됐다 반복함으로 롤백을 시킬수가 없어 어쩔수 없이 트랜잭션 경계를 UserService에서 설정해야한다. public void upgradeLevels() throws Exception { Connection c = dataSource.getConnection(); try { // 유저 등급 업그레이드 비지니스 로직 user.upgradeLevel(); userDao.update(c, user); // j..
초난감 예외처리 // 무책임한 회피 throws public void method1() throws Exception { throw new Exception("This is a test"); } public void method2() throws Exception { method1(); } public void method3() throws Exception { method2(); } // catch 하지만 아무것도 하지 않음 public void method4() throws Exception { try { method1(); } catch (Exception e) { // Do nothing } } 예외처리 방법 복구 예외를 잘 파악하고 정상흐름으로 돌리는 조치를 취하는것 (ex. 다른 대안을 제시,..
1장에서 초난감 dao 에서 커넥션 생성에관한 책임분리를 DI와 IOC에 대해 배우면서 진행했고 이번장에서는 탬플릿/콜백 패턴을 배우면서 쿼리만드는것을 제외한 모든 책임을 분리하고 코드 중복을 없애는 리팩토링 과정을 보여준다. 0. 리소스 반환을 위해 try catch 범벅 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 e..
테스트에 대한 사용법 같은 부분은 생략하고 새로 알게된 부분 위주로 정리 1장에서 살펴봤던 Ioc, DI 같은 객체지향 기술은 요구사항 변화에 유연하게 대응하는데도 도움이 되지만 테스트를 짜게 쉽게 만드는데도 도움이 된다. 그래서 테스트를 짜지 않는다면 스프링이 주는 가치중 많은 부분을 포기하는 셈이다. ApplicationContext 매번생성되는 문제점 각 테스트가 독립적으로 실행되는것을 보다 확실하게 보장하기 위해서 매번 오브젝트를 생성한다. public class UserDaoTest { private UserDao dao; @Before void setUp(){ ApplicationContext context = new GenericXmlApplicationContext("applicationC..
