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..
책에서 소개하는 예제를 통해서 스프링은 왜이렇게 생겼는가 이해해 볼수 있는 챕터 스프링의 철학 ejb 가 커지면서 잃어버렸던 객체지향을 다시 잘 적용해보자 ejb 가 많은 기능을 제공하지만 서비스로직에 컨테이너를 쓰기위한 코드들이 많이 침투됐다함 객체지향을 해야하니까 오브젝트에 많은 관심을 둔다. 오브젝트가 어떻게 생기고 없어지고 사용되는지 오브젝트를 다루는 베스트프랙티스를 프레임워크단에서 제공해버리기 첫번째, 관심사의 분리 왜 해야 하는가? 소프트웨어는 여러가지 요구사항에 의해 항상 변화하고 개발자는 변화를 어느정도 대비하면서 개발을 해야함 관심사를 분리하지 않으면 db 암호를 바꾸려고 모든 dao를 변경해야하는등 수정에 유연하지 못하게 됨 응집도 높고 결합도 낮은 코드를 만들기 위해 노력하자 User..
실무중에 클라이언트에서 request를 form-url-encoded 방식으로 보내는데 그중에 배열의 표기가 [ ] 를 사용할때 매핑에러가 났었다 list[]=1&list[]=2 이런식으로 배열을 url 방식으로 표기할때 명확한 표준이 없는 것 같다. list=1&list=2도 가능하다 @RestController class TestController { @PostMapping("/url-encode") fun urlEncode(body: TestBody): String { println(body) return "ok" } @PostMapping("/json") fun json(@RequestBody body: TestBody): String { println(body) return "ok" } } da..