Toby’s 스프링 3.0 완독

아직 나오지도 않은 책을 벌써 완독했다. 캬.. 이런 특권이 있나…

열심히 봤는데 10일정도 걸린것 같다. 읽는 족족 소화되는 내용들이 아니라서 좀 힘들다. 마지막에 읽은 내용들은 AOP과 LTW, 콘텍스트 테스트 프레임워크, 스프링 기타 기슬과 스프링 학습법 이었다. 마지막 부분인데 지면 관계상인지 이 책의 앞부분에 비하면 다소 함축적이었다.
나도 그동안 감상을 수도 없이 적었으니 이번엔 생략이다.ㅋ
이 책의 앞에서는 열심히 테스트로 내용 검증도 해주고 그랬었는데 2부에 들어서면서부터 방식이 바뀌었다. 그렇다고 해당 내용 검증을 하지 않을 분이 아니다. 저자인 Toby님은 완벽주의자다. 이 책과 같이 제공될 소스 코드에 보면 책에서 언급한 내용을 일일히 테스트 코드로 작성한 것을 볼 수 있다. 
다음 봄싹 스터디에서는 해당 테스트 코드를 가지고 스터디를 해볼까 생각중이다. 또 해당 테스트 코드를 오픈 소스로 계속 다듬어 볼 생각도 있다. 학습 테스트를 오픈소스로 만들어 두면 차후에 스프링을 처음 쓰거나 해당 기능을 처음 쓰는 사람들에게 도움이 될 것 같다.

Toby’s 스프링 3.0 @MVC를 읽고서

하악하악… 무려 워드로 130p 가까운 걸 읽었더니 머리가 혼란스럽다. 내가 잘모르던 것이 가장 많이 등장한 챕터인것 같다. 챕터 제목이 @MVC 라고 스프링 레퍼런스에 있는 @MVC 부분과 대응해서 생각했다간…

ㅎㅎㅎㅎ…….

이번 장의 겉모습은 @MVC 이지만 난 왠지 스프링 MVC 확장 프레임워크에 대한 힌트를 얻은 것 같다. 솔직히 말해서 대충 쓰려면 몰라도 되는 것들이 제법 있지만 그건 정말 대충 쓸 때의 이야기이고 스프링 강의를 한다던지, 스프링 @MVC 기반 프레임워크를 만들거라든지, 제대로 알고 쓰고 싶다는 경우에는 반드시 알아야 하는 내용들이 가득 들어있다. 지면 관계상 다소 함축적으로 설명한 부분도 없자나 있다. 그런 부분은 API나 레퍼런스를 보면 쉽게 알 수 있을 것이고 저자가 권하듯이 소스 코드를 보면 더 확실하게 알 수 있을 것 같다.
이번 장은 맨 처음부터 끝까지 긴장하면서 봐야했다. 그래서 좀 힘들었다. 아 마지막에 form 태그 설명할떈 조금 쉬엄쉬엄 봤는데 그전까진 정말 뇌가 100m 달리기를 하는듯한 기분이다. 그중에서 틀린 설명이나 잘못된걸 집어내라고 하니 머리가 빠질것 같은 기분이다. 번데기에서 주름 없는 곳을 찾으란 얘기랑 같은 거다.
이 장에서 제일 재밌게 본 부분은 상속 관계에서 @RequestMapping 동작 방식이다. 그밖에도 스프링 3에 추가된 컨버터와 포매터 그리고 모델의 일생, 메시지 컨버터, @MVC 확장 포인트 등을 설명해준다. @MVC를 사용해온지 꽤 됐는데도 모르는 기능이 많았다. 마지막 부분에는 핸들러 메서드의 인자로 받을 수 있는 것을 확장하는 방법도 나오는데 정말 대박이었다.. 뭐 이런 기능들까지 있나 싶을정도로.. 까오..
이제 나머지를 달려야겠다.

Toby’s 스프링 3.0 스프링 웹 기술과 스프링 MVC를 읽고서…

난 그동안 스프링 MVC를 잘 몰랐다. 다행이다. 이제는 좀 알것같다. 대충 머리속에 그려진다. 지난번 소녀시대 스프링 @MVC를 발표할 때 아주 중요한 스프링 MVC 구성요소 몇가지를 소개했었다. 물론 그것들 보다는 소녀시대 이름만 외우고 가신 분들이 많겠지만;; 이 책에서는 모든 구성요소를 다 설명해주며 그 구성요소군에 속해있는 여러 요소들의 특징과 사용법도 설명해주고 있다. 물론 지면 관계상 뷰 기술중 대부분은 생략이지만 간단한 확장 방법을 통해서 충분히 다른 것들의 사용법도 예상할 수 있었다.

가장 기가막힌 부분은 스프링 Controller(API)와 핸들러 어댑터를 확장해서 새로운 형태의 컨트롤러를 만들어 사용하는 방법이었다. 이 부분은 정말 스프링 MVC 정복기라고 부르고 싶은 부분이다. 물론 호불호가 갈릴만한 부분이기도 하다.

하지만 그런 지식과 실천은 꼭 필요하다. 왜냐면 스프링이 제공하는 웹 계층 구현방법이 너무 다양하기 때문이다. 그것을 정책으로 통일시킬 수 있겠지만 더 좋은건 그 정책을 코드에 반영하는 것이 필요하고 그것을 기반으로 코드를 작성하면 규모가 큰 프로젝트라 하더라도 코드의 일관성을 유지할 수 있을 것이다. 프레임워크 개발이 필요한 이유가 바로 이때문이 아닐까? 프레임워크를 사용하는 이유는 둘 중 하나인것 같다. 프레임워크가 강요하는 정책을 따르기로 결정했거나, 그 프레임워크를 기반으로 프로젝트 고유의 정책과 특성을 반영한 추상계층을 만들어 낼 수 있기 때문인 것 같다. 스프링은 기본적인 방법들은 제공하지만 어떤 방법을 강요하지는 않는다. 따라서 개발자마다 코딩 스타일이 많이 다를 수 있는데 그것을 해결할 수 있는 방법을 소개해준다.
또한 스프링 3.0 최신 기술 중에 컨텐츠 네고 기법을 사용한 뷰 리졸버 설명이 기가 막힌다. 전혀 간단하지 않은 동작 원리를 쉽게 풀어 설명해주어 이해하기 편했다. 이 부분은 레퍼런스나 API에서도 설명이 빈약해서 직접 소스코드를 분석해가며 쓰셨다고 하니 그저 감사할 따름이다.
마지막으로 이 책에서 정의한 프레임워크 개발에 대한 글을 (저자의 허락-‘살짝쿵 스포일러를 넣어도 대
‘-하에) 옮겨본다. 

프레임워크 개발이란 이미 있는 기술을 조합해서 어떻게 쓸지 결정하고 툴이나 공통 모듈 정도를 만들어 놓는 것이 아니다. 프레임워크란 애플리케이션의 코드가 효율적인 방법으로 개발되서 사용될 수 있도록 새로운 틀(framework)을 만드는 작업이다.”

ps: 이번 장을 보면서 새로운 형태의 OSAF 3.0을 개발해야겠고 다짐했다.

Toby’s 스프링 3.0 스프링 웹 기술과 스프링 MVC를 읽으며..

아직 다 못봣다. 1/3정도 봤는데 기본적인 스프링 MVC 구성요소와 흐름을 상세하게 설명해주고 있다. 지난 KSUG 발표때 소녀시대 이용해서 설명했던 바로 그 부분이다. 그 뒤에는 스프링 MVC 테스트가 나온다. 캬.. 이 부분이 대박이다.

스프링 웹 계층 테스트는 잘 만들질 않는다. 귀찮다. Mock머시기 클래스의 객체들 만들고 컨트롤러 실행시켜서 ModelAndView 받아서 확인하는 아주 간단한 테스트 조차 너무 귀찮다. 그런데 그런 것 말고 어떤 URL을 스프링이 처리하는지.. 안하는지 보려면 DispatcherServlet까지도 테스트 범위에 들어가야 한다. 그리고 그 결과를 가져와야 하는데 그게 막상 해보면 알겠지만 좀 귀찮은 것이 아니다. 그래서 그냥 스프링이 알아서 테스트 했겠지 생각하고 넘어가기 일수다.
하지만 그러면 안된다. 제대로 확인도 안해보고 막연한 상상에 기대어 살면 안된다. @RequestMapping 같이 생소한 방법을 사용할 땐 더더욱 그렇다. 그래서 테스트가 필요하다. 단, 편하게 할 수 있어야 되는데 바로 그 “편하게 MVC 테스트하는 방법”을 제공해 준다. 여기서 소개한 방법을 응용해서 얼마든지 자신이 확인하고 싶은 것을 확인할 수 있다. 그럼 더이상 막연한 상상에 기대어 코딩하는 일은 없어질 것이다. 좀 더 확신을 가지고 마음 편한 상태에서 코딩할 수 있게 될 것 같다.
물론,, 테스트 안해도 맘편하다면.. 어쩔 수 없다.ㅋ

Toby’s 스프링 3.0 데이터 액세스 기술을 읽고서

JDBC, iBatis, JPA, Hibernate를 사용하여 DAO를 사용하는 방법과 로컬 트랜잭션, JTA 트랜잭션 사용법까지 나와있다. 특히 이중에서 내가 자주 안써본 JDBC, iBatis, JPA 내용과 JTA 트랜잭션이 꽤 재미있었다.

JDBC 코딩 하시는 분들께는 거의 필수인 JdbcTemplate이나 SImpleJdbcTemplate은 대부분 익숙할 것이다. 하지만 그게 끝이 아니었다. 이것들을 기반으로 객체 지향 API로 쿼리 객체를 만들고 재사용할 수 있는 API도 제공한다. 스프링 빨간책에서 커맨드 패턴과 JdbcTemplate을 이용해서 한단계 더 추상화 시킨 SqlUpdate와 SqlQuery를 볼 수 있었는데 그보다 더 개선된 새로운 API인것 같다. (SimpleJdbcInsert API를 보니 2.5에 추가된 것인가 보다.)
iBatis보다는 JPA 내용이 더 재미있었다. 최근 JPA 2.0이 발표되면서 Hibernate를 JPA 프로파이더로 사용하고 JPA를 사용해볼까 고민하던 중이었기 때문인지도 모르겠다. 하지만 그 뿐이 아니다 JPA를 사용하는 방법에는 어떤 것들이 있고 각각의 장단점 비교가 나온다. 특히 이부분에서 CDI와 관련된 스코프 관련 내용도 나오는데 예전에 토비님 블로그에서 이상한 공격(?)을 받았던 글이 떠올랐다. 그 둘을 연관지어서 읽어보면 더 재미있을 것 같다.
Hibernate는 JPA에 비해 적용방법은 간단해 보였다. 이유는 JPA 처럼 좀 더 쉽게 쓰게 해주려는 마술을 적용하지 않았기 때문일 것이다. 그래서 매번 .getCurrentSession()을 해줘야하지만 머.. 결국은 선택이다.
또 KSUG 포럼에 종종 올라오는 질문 중에 하나인 트랜잭션 관련 내용이 알차다. 데이터소스 하나 트랜잭션 매니저 하나인 아주 간단한 경우부터 JTA까지 다룬다. 톰캣에서 JTA를 사용하는 예제까지 보여주고 있으며 하나의 데이터베이스에 대한 JDBC, 하이버 DAO가 있을떄 어떻게 그리고 어떤 트랜잭션 매니저를 왜 사용하면 되는지 설명해준다. 그밖에 여러 경우를 전부다..
오늘도 별로 꼬투리 잡을께 없다. +_+