Whiteship's Note


Toby's 스프링 3.0 완독



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

열심히 봤는데 10일정도 걸린것 같다. 읽는 족족 소화되는 내용들이 아니라서 좀 힘들다. 마지막에 읽은 내용들은 AOP과 LTW, 콘텍스트 테스트 프레임워크, 스프링 기타 기슬과 스프링 학습법 이었다. 마지막 부분인데 지면 관계상인지 이 책의 앞부분에 비하면 다소 함축적이었다.

나도 그동안 감상을 수도 없이 적었으니 이번엔 생략이다.ㅋ

이 책의 앞에서는 열심히 테스트로 내용 검증도 해주고 그랬었는데 2부에 들어서면서부터 방식이 바뀌었다. 그렇다고 해당 내용 검증을 하지 않을 분이 아니다. 저자인 Toby님은 완벽주의자다. 이 책과 같이 제공될 소스 코드에 보면 책에서 언급한 내용을 일일히 테스트 코드로 작성한 것을 볼 수 있다. 

다음 봄싹 스터디에서는 해당 테스트 코드를 가지고 스터디를 해볼까 생각중이다. 또 해당 테스트 코드를 오픈 소스로 계속 다듬어 볼 생각도 있다. 학습 테스트를 오픈소스로 만들어 두면 차후에 스프링을 처음 쓰거나 해당 기능을 처음 쓰는 사람들에게 도움이 될 것 같다.

저작자 표시
신고
top


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



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

이번 장의 겉모습은 @MVC 이지만 난 왠지 스프링 MVC 확장 프레임워크에 대한 힌트를 얻은 것 같다. 솔직히 말해서 대충 쓰려면 몰라도 되는 것들이 제법 있지만 그건 정말 대충 쓸 때의 이야기이고 스프링 강의를 한다던지, 스프링 @MVC 기반 프레임워크를 만들거라든지, 제대로 알고 쓰고 싶다는 경우에는 반드시 알아야 하는 내용들이 가득 들어있다. 지면 관계상 다소 함축적으로 설명한 부분도 없자나 있다. 그런 부분은 API나 레퍼런스를 보면 쉽게 알 수 있을 것이고 저자가 권하듯이 소스 코드를 보면 더 확실하게 알 수 있을 것 같다.

이번 장은 맨 처음부터 끝까지 긴장하면서 봐야했다. 그래서 좀 힘들었다. 아 마지막에 form 태그 설명할떈 조금 쉬엄쉬엄 봤는데 그전까진 정말 뇌가 100m 달리기를 하는듯한 기분이다. 그중에서 틀린 설명이나 잘못된걸 집어내라고 하니 머리가 빠질것 같은 기분이다. 번데기에서 주름 없는 곳을 찾으란 얘기랑 같은 거다.

이 장에서 제일 재밌게 본 부분은 상속 관계에서 @RequestMapping 동작 방식이다. 그밖에도 스프링 3에 추가된 컨버터와 포매터 그리고 모델의 일생, 메시지 컨버터, @MVC 확장 포인트 등을 설명해준다. @MVC를 사용해온지 꽤 됐는데도 모르는 기능이 많았다. 마지막 부분에는 핸들러 메서드의 인자로 받을 수 있는 것을 확장하는 방법도 나오는데 정말 대박이었다.. 뭐 이런 기능들까지 있나 싶을정도로.. 까오..

이제 나머지를 달려야겠다.
저작자 표시
신고
top


Toby's 스프링 3.0 스프링 웹 기술과 스프링 MVC를 읽고서...



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

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

하지만 그런 지식과 실천은 꼭 필요하다. 왜냐면 스프링이 제공하는 웹 계층 구현방법이 너무 다양하기 때문이다. 그것을 정책으로 통일시킬 수 있겠지만 더 좋은건 그 정책을 코드에 반영하는 것이 필요하고 그것을 기반으로 코드를 작성하면 규모가 큰 프로젝트라 하더라도 코드의 일관성을 유지할 수 있을 것이다. 프레임워크 개발이 필요한 이유가 바로 이때문이 아닐까? 프레임워크를 사용하는 이유는 둘 중 하나인것 같다. 프레임워크가 강요하는 정책을 따르기로 결정했거나, 그 프레임워크를 기반으로 프로젝트 고유의 정책과 특성을 반영한 추상계층을 만들어 낼 수 있기 때문인 것 같다. 스프링은 기본적인 방법들은 제공하지만 어떤 방법을 강요하지는 않는다. 따라서 개발자마다 코딩 스타일이 많이 다를 수 있는데 그것을 해결할 수 있는 방법을 소개해준다.

또한 스프링 3.0 최신 기술 중에 컨텐츠 네고 기법을 사용한 뷰 리졸버 설명이 기가 막힌다. 전혀 간단하지 않은 동작 원리를 쉽게 풀어 설명해주어 이해하기 편했다. 이 부분은 레퍼런스나 API에서도 설명이 빈약해서 직접 소스코드를 분석해가며 쓰셨다고 하니 그저 감사할 따름이다.

마지막으로 이 책에서 정의한 프레임워크 개발에 대한 글을 (저자의 허락-'살짝쿵 스포일러를 넣어도 대
'-하에) 옮겨본다. 
"프레임워크 개발이란 이미 있는 기술을 조합해서 어떻게 쓸지 결정하고 툴이나 공통 모듈 정도를 만들어 놓는 것이 아니다. 프레임워크란 애플리케이션의 코드가 효율적인 방법으로 개발되서 사용될 수 있도록 새로운 틀(framework)을 만드는 작업이다."

ps: 이번 장을 보면서 새로운 형태의 OSAF 3.0을 개발해야겠고 다짐했다.
저작자 표시
신고
top


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



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

스프링 웹 계층 테스트는 잘 만들질 않는다. 귀찮다. Mock머시기 클래스의 객체들 만들고 컨트롤러 실행시켜서 ModelAndView 받아서 확인하는 아주 간단한 테스트 조차 너무 귀찮다. 그런데 그런 것 말고 어떤 URL을 스프링이 처리하는지.. 안하는지 보려면 DispatcherServlet까지도 테스트 범위에 들어가야 한다. 그리고 그 결과를 가져와야 하는데 그게 막상 해보면 알겠지만 좀 귀찮은 것이 아니다. 그래서 그냥 스프링이 알아서 테스트 했겠지 생각하고 넘어가기 일수다.

하지만 그러면 안된다. 제대로 확인도 안해보고 막연한 상상에 기대어 살면 안된다. @RequestMapping 같이 생소한 방법을 사용할 땐 더더욱 그렇다. 그래서 테스트가 필요하다. 단, 편하게 할 수 있어야 되는데 바로 그 "편하게 MVC 테스트하는 방법"을 제공해 준다. 여기서 소개한 방법을 응용해서 얼마든지 자신이 확인하고 싶은 것을 확인할 수 있다. 그럼 더이상 막연한 상상에 기대어 코딩하는 일은 없어질 것이다. 좀 더 확신을 가지고 마음 편한 상태에서 코딩할 수 있게 될 것 같다.

물론,, 테스트 안해도 맘편하다면.. 어쩔 수 없다.ㅋ
저작자 표시
신고
top


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가 있을떄 어떻게 그리고 어떤 트랜잭션 매니저를 왜 사용하면 되는지 설명해준다. 그밖에 여러 경우를 전부다..

오늘도 별로 꼬투리 잡을께 없다. +_+
저작자 표시
신고
top


Toby's 스프링 3.0 10장 IoC 컨테이너와 DI를 읽고서



결론은 다시보고 있다. 다시 보고 싶은 부분이 생겼다. 들어있는 내용이 꽤 많기 때문에 그 중에서 더 자세히 살펴보고 싶은 부분이 분명히 생길것이다. 그래서 결국 나처럼 다시 보게 될 것이다.

이 책을 쓰느라 얼마나 많은 노력과 학습을 하셨는지 이 장에 잘 묻어나온다. 특히 모든 빈 등록 방법 설명, 장단점 비교, 전략 분석. 모든 빈 의존관계 설정 방법 설명, 장단점 비교, 전략 분석은 토비님의 완벽주의 성향을 잘 드러낸다.

스프링 웹 애플리케이션은 거의 대부분 애플리케이션 콘텍스트 상속 구조로 되어있다. 이것을 잘 이해하지 못하면 AOP가 적용되지 않는다느니 트랜잭션이 되지 않느다느니 원인을 찾기도 힘든 문제들을 만들어 낼 수도 있고 그 문제를 해결하지도 못한다. 그것에 대한 아주 명확한 이해와 해결책을 제시하는 내용이 들어있다. 이걸 모르고 스프링 개발을 하고 있다면 무늬만 스프링 개발자라고 하고 싶을 정도로 중요한 내용이기 때문에 반드시 숙지하도록 하자.

프로토타입과 관련된 내용도 주옥같다. 아주 오래전 KSUG 포럼에 프로토타입 스코프 빈을 참조하는 싱글톤 스코프 빈이 있을때 프로토타입 스코프가 제대로 동작하도록하는 여러가지 방법을 논의한적이 있었다. 사실은 Toby님의 일방적인 퀴즈에 불과했지만 그때 메신저를 통해 들었던 정답과 그 이후에 추가된 해결책까지도 설명하고 있다. 레퍼런스나 API 문서를 빠듯하게 뒤져도 안나올만한 방법이 소개되고 있다. 싱글톤 빈만 사용하면 되지 머.. 라고 안일한 생각을 가진 스프링 사용자가 아니라면 꼭 살펴보고 학습해야 한다.

이밖에도 레퍼런스나 API 문서에서 조차 찾기 힘든 내용이 한둘이 아니다. 그런 내용을 이렇게 친절하게 설명해주는.. 그것도 한글로 된 책을 볼 수 있다는 것은 가히 축복이다.

아. 마지막으로 꼬투리 하나만 잡자면 왠지 10장부터는 약간 토비님 블로그를 읽는 느낌이 난다. 그런데 어쩔 수 없다 저 많은 내용을 더 쉬운 말투와 구체적인 설명과 그림으로 다 풀어내려면 200~300p짜리 책한권이 될 것 같다. 내용자체가 쉽지 않기 때문일 수도 있다. 그렇다고 무슨 안드로메다 수학공식도 아니니까 겁먹진 말자.
저작자 표시
신고
top


Toby's 스프링 8, 9장을 읽고서



8장은 스프링에 관한 이야기이다. 스프링이란 무엇인가? 스프링의 목적? 그 목적을 달성하는 방법을 설명하며 스프링 삼각형이라 불리는 IoC/DI, AOP, PSA를 자세히 설명해준다. 또한 POJO 프로그래밍에 대해 설명한다. 

그 중에서 기억에 남는 부분은 "복잡함을 해결한다."라는 부분인데 이 이야기는 2008년 Spring One Ameria 컨퍼런스에 참석하여 직접 들은 이야기라 감회가 새로웠다. 여기서는 그 복잡함이란 무엇인지 또 스프링은 그것을 어떻게 제압하겠다는 것인지 잘 설명해주고 있다.

POJO 프로그래밍에 대한 내용역시 유익하다. POJO라는 단어가 난무하는 요즘 POJO에 대해 제대로 집고 넘어갈 필요가 있는데 그런 간지러움을 잘 긁어주고 있다. 특히 평소 JPA를 사용한 도메인 클래스가 POJO인건지 아닌건지 고민이었는데 그런 고민을 해결하는데 실마리를 제공해주는 기준을 제시하고 있다.

이외에 스프링 삼각형에 대해서는 이미 1부에서 찐하게 살펴본 내용을 이론적으로 점검하는 기분이 들었다. 원래는 8장이 제일 처음이었다고 했는데 1부 맨 뒤로 돌리신건 100번 잘하신것 같다. 아무래도 8장부터 읽기 시작했다면 지레겁먹고 책을 덮었을 수도 있겠다.

9장은 본격적인 2부 시작으로 뭔가 코딩을 할 것 같은 기세이다. 프로젝트를 세팅하고 아키텍처를 논한다. 프로젝트는 세팅이야 스프링 책인지라 STS와 Eclipse+Spring IDE 이야기가 주를 이룬다. 가장 흥미롭우며 9장의 주를 이루는 부분은 사실 그 뒤에 있는 아키텍처 이야기다. 이 부분 토비님 세미나에서 다룰 주제이기도 하고 개인적으로 가장 궁금한 부분이기도 했다. 이 부분을 읽으면서 예전에 시도하다 말았던 아키텍처를 다시 한번 시도해보고 싶다는 생각이 들었다.

자.. 이제 드뎌 10장을 달릴 차례다.
저작자 표시
신고
top


Toby's 스프링 핵심기술 응용을 읽고서..



먼저 이 장의 제목은 별로다. 이 장에 들어있는 내용을 다 나타내고 있지 못하다. 흠.. 읽고나서 다시 제목을 생각해보니 이번 장은 "스프링 스타일 코딩"이 더 좋을지도 모르겠다.

이번 장에서 살펴볼 수 있었던 스프링의 기능은 내가 미처 몰랐던 기능인 내장 DB 지원 기능을 비롯해서 3.0에 새로 추가된 OXM 그리고 필수로 알아야 하는 리소스 지원 등을 다루고 있다. 이 기능들을 유기적으로 연결하여 SqlService라는 것을 개발하는데 그 과정이 정말이지 놀랍다.

왜 놀라운지는 읽어보는 사람들만이 알수 있겠지만, 이 장을 읽으면서 내내 느낀점은 이 책은 스프링 사용자 뿐 아니라 모든 개발자가 읽어야 한다는 것이다. 이번장에서 SOLID라 일컫는 객체 지향 기본 원칙들을 아무런 거부감 없이 자연스럽게 살펴볼 수 있으며 사용하기 좋은 API 설계 방법이나 점진적인 변화, 진화를 통한 개발 방법을 살펴볼 수 있다. 이런것들은 상당히 딱딱하고 탁상공론 적이며 형이상학적인 주제가 될 수 있는데 반해 이 책에서는 그것들을 항상 눈에 보이는 코드와 테스트를 가지고 증명해 보인다. 또한 이 책의 스타일인 '차분차분'과 '단계적'인 방법을 통해서 살펴보기 때문에 체할 걱정은 없으며 굉장히 실용적이다.

지난주 봄싹 디자인패턴 스터디에서 SOLID 원칙을 학습했지만 탁상공론에 그칠만한 내용밖에 못다뤄 굉장히 아쉬웠다. 물론 이론적인 내용도 필요하다지만 사실 그런 이론은 시험 볼때나 필요한 것이지 코딩에는 별 도움이 안 된다. 코딩에 도움이 되지 않는 이론이 무슨 소용이란 말인가. 순수 이론으로써의 가치를 가지고자 정리된 원칙들이 아닐 것이다. 그러한 원칙들을 고려하여 코딩하는 것이 어떤 것인지... 그로인해 어떤 스타일의 코드가 탄생되는지 보고 싶다면 이 책을 꼭 보시라권하고 싶다.

나 역시 백날 스프링을 쓰면 머하나.. 스프링에 어울릴만한 코드는 한 줄도 작성하지 못하는데.. 라며 자괴감에 빠졌던 적이 있다. 머 그렇다고 지금도 크게 달라진건 없지만 이 챕터가 그러한 자괴감에서 나를 꺼내주는데 한몫 할것 같다. 역시 이 책은 스프링을 발판삼아 더 나은 개발자가 되고 싶은 분들을 위한 책이다. 자 이제 2부를 달려보자.
저작자 표시
신고
top







티스토리 툴바