Whiteship's Note


[토비의 스프링 3] 2차 완독 후기



결국 추천사를 쓸 수 있게 됐습니다. 캬캬캬.
배려해주신 출판사 부사장님과 토비님께 감사드립니다. 잘 쓸께요. 아.. 부담 100배!!!!



----------------지난 이야기-----------------

사실 완독이라고 할 수는 없다. 이번엔 강의 준비를 하면서 다시 봤는데 강의할 부분만 읽었기 때문에 모든 글을 다시 읽진 않았다. 읽으면서 중간 중간 코드와 API 설명이 나온 부분을 유심히 보면서 혹시 소스 코드에 잘못된 것은 없는지 검증하는 작업을 했다. 내가 빅뱅의 쉘든 같은 사람이었다면 완벽하게 리뷰를 할 수 있었을텐데 난 레너드 수준에서 리뷰를 마감했다. 1차 때 보다 훨씬 적운 수의 리뷰를 드렸지만 품질 만큼은 1차때 보다 더 나은 리뷰를 해드린것 같아 다행으로 생각하고 있다. 그래도 분명히 놓친 부분이 있을텐데... 그건 개정판을 내실 때 수정할 수 있도록 출판사에 제보해주면 좋겠다. 아마 별도의 페이지가 있을지 싶다.

한 가지 아쉬움이 남는다. 난 추천사를 못 썼다. 근래 가장 많은 시간과 애정을 쏟아가며 리뷰한 책이고 그 누구보다도 여러 개발자에 이 책을 추천해주고 싶었는데 그럴 수 없었다. 여태까지 본 책 중에 이렇게까지 자발적으로 추천사를 쓰고 싶은 책은 없었는데 조금 안타깝다. 

내가 이 책을 리뷰 한 것은 이 책에 내가 적은 글을 남기고 싶어서도 아니고 돈을 받고 싶어서도 아니고 강의를 하고 싶어서도 아니었다. 돈은 애초에 생각도 안했고, 강의는 이미 리뷰를 시작한 다음에 계획 됐다. 추천사는 이 책을 읽다보니 너무도 쓰고 싶어졌지만 이젠 상관없다. 난 그냥 이 책 내용이 정말 좋았고 많은 도움을 받았다. 나도 어떻게든 이 책이 조금 더 반짝거리게 해주고 싶었다. 또 기나긴 여정에서 고군분투 하시는 토비님에게 조금이나마 힘이 되고 싶었다. 그것으로 됐다.
top

  1. Favicon of http://koko8829.tistory.com BlogIcon 열이아빠 2010.07.16 17:48 PERM. MOD/DEL REPLY

    추천사를 못쓰신것이 아쉽다는것보다
    더 강렬한 추천의 글은 없을것 같습니다. ^^
    기대가 되네요.

    Favicon of http://whiteship.me BlogIcon 기선 2010.07.16 19:26 PERM MOD/DEL

    ㅎㅎㅎ그랬나요.

  2. Favicon of http://yunsunghan.tistory.com BlogIcon Max 2010.07.16 18:19 PERM. MOD/DEL REPLY

    서운함이 느껴지네....
    걱정이네요, 너무 기대치를 높여 놔서....-_-;;;

    Favicon of http://whiteship.me BlogIcon 기선 2010.07.16 19:26 PERM MOD/DEL

    절대로.. 제 블로그의 모든 글을 걸어도 좋습니다.
    실망하실 일 없습니다.

  3. Favicon of http://toby.epril.com BlogIcon 토비 2010.07.16 19:49 PERM. MOD/DEL REPLY

    기선이 추천사도 싣기로 결정!

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2010.07.16 20:37 신고 PERM MOD/DEL

    ㄱㅅㄱㅅ!!

  4. Favicon of http://moer.egloos.com BlogIcon mOer 2010.07.18 16:28 PERM. MOD/DEL REPLY

    빅뱅 재미있죠 :-)

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2010.07.18 20:10 신고 PERM MOD/DEL

    넌 라즈...

Write a comment.


Toby's 스프링 3.0 완독



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

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

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

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

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

top

Write a comment.


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



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

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

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

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

이제 나머지를 달려야겠다.
top

  1. Favicon of http://helols.pe.kr BlogIcon isyoon 2010.05.19 18:33 PERM. MOD/DEL REPLY

    어디삼.. ? ;; 문자도 쌩하시고 ㅡㅡ;; 블로그에만 나타나네용!

    Favicon of http://whiteship.me BlogIcon 기선 2010.05.19 19:58 PERM MOD/DEL

    퇴근했지;

    leave me alone.

    Favicon of http://helols.pe.kr BlogIcon isyoon 2010.05.19 20:43 PERM MOD/DEL

    ㅇㅋ! see you later!

Write a comment.


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



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

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

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

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

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

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

Write a comment.


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



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

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

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

물론,, 테스트 안해도 맘편하다면.. 어쩔 수 없다.ㅋ
top

Write a comment.


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

Write a comment.


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



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

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

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

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

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

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

  1. Favicon of http://blog.outsider.ne.kr BlogIcon Outsider 2010.05.13 14:08 PERM. MOD/DEL REPLY

    빨리 출간되었으면 좋겠다....

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2010.05.13 14:21 신고 PERM MOD/DEL

    흐흐 10권씩 사서 사내에 돌리셔야 되요.

    Favicon of http://blog.outsider.ne.kr BlogIcon Outsider 2010.05.13 19:35 PERM MOD/DEL

    10권... ㄷㄷㄷㄷ

    Favicon of http://whiteship.me BlogIcon 기선 2010.05.14 11:11 PERM MOD/DEL

    대충 언제쯤 나올것 같다는 이야기는 들었는데..
    기밀인것 같아서 말은 못하겠군요.

    머.. 올해에는 나올테니.. 어서 다른 스터디를 끝내야겠어요.

  2. Favicon of http://architect.tistory.com BlogIcon 짱가 2010.05.13 18:48 PERM. MOD/DEL REPLY

    저도 돌릴듯.. ^^
    벌써 읽고 계시는 군요~~~ ^^

    Favicon of http://whiteship.me BlogIcon 기선 2010.05.13 19:12 PERM MOD/DEL

    넵 많이 많이 돌려주세요.
    개발자 수준을 업그레이드 할 수 있는 절호의 기회에요.

    물론 실천하지 않으면 꽝이지만;;

  3. Favicon of http://moova.tistory.com BlogIcon moova 2010.05.14 10:38 PERM. MOD/DEL REPLY

    저는 출판되면 사서 봐야겠네요.
    병상중이라 리딩을 못하는게 아쉽기만 하군요. 제가 교육을 하거나 받을 때 항상 느꼇던 점을 잘 지적해 주셨군요. 레퍼런스 위주나 api위주의 교육은 개발자의 수준을 올려놓지는 못한다고 봅니다.
    (물론 눈치빠르고 똑똑한 개발자라면 하나를 보고 열을 깨우치치만:^^ .. 5년전에 AspectJ책을 사보고 참 놀라운 마음에 설레였던 적이 있었는데... 다시 그 갈증을 체험해 보고 싶군요. )

    레퍼런스와 api에서 얻지 못한 지혜를 이 책을 통해서 얻었으면 하는 바램입니다.:) 기대되는 군요~~

    whiteship님에게 권유하는 내용은 아니지만 ( http://moova.tistory.com/entry/RequirementStory ) 읽어보셨으면 합니다.

    그리고.. 허공에 대고 좀 블로깅 하지 말고. 트랙백도 날리면서 좀 포스팅 해여~ㅎㅎ

    Favicon of http://whiteship.me BlogIcon 기선 2010.05.14 11:12 PERM MOD/DEL

    RSS 리더기에서 벗어난지 반년 정도 됐네요.

    드디어 내가 리더기 종속성에서 해방됐구나.. 라는 자유와 함께..다른 분들이 어떤 글을 쓰고 있는지 모르겠다는 부작용이.. 쿨럭;;

    헐.. 그나저나 아프시다니요;; IT 보단 건강이죠.

Write a comment.


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

Write a comment.


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



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

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

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

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

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

  1. Favicon of http://rudalson.tistory.com BlogIcon 없다캐라 2010.05.10 11:28 PERM. MOD/DEL REPLY

    이게 지금 나온 책인가요? 아님 토비님이 저술중인 상태인가요?

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2010.05.10 12:52 신고 PERM MOD/DEL

    현재 저술중이신 책입니다. 조만간 보실 수 있을 듯...

Write a comment.


Toby's 스프링 AOP 마무리



지금은 스프링 AOP를 넘어서 스프링 활용 부분을 읽고 있는데 기억에서 떠나기 전에 정리해둬야겠다.

 AOP 챕터가 다소 크다는 느낌을 받았다. 스프링 AOP 기능 뿐 아니라 트랜잭션에 관한 설명도 상당 부분이 나온다. 하지만 스프링 트랜잭션을 이해하려면 스프링 AOP에 대한 이해가 필수적이고 스프링 AOP를 이해하기 위한 좋은 예로 스프링 트랜잭션 만큰 좋은 것도 없다고 생각이 든다. 따라서 스프링 AOP를 설명한 굉장한 분량만큼이나 그 노고를 느낄 수 있었다. 특히 중간 중간 텍스트로 인해 지칠 수 있는 독자들을 위한 그림들은 상당히 단순 명료하면서도 배려적이다.

그 중에서 가장 눈길을 끈 곳은 포인트컷 테스트였다. 정말 대박이었다. 예전에 읽었을 때에도 감명을 받고 사실 그 내용을 바탕으로 포인트컷 표현식 테스트에 대한 블로깅까지 했던적이 있다. AOP를 사용할 때 항상 고민하던 부분이었다. 도대체 이 포인트컷이 어디에 적용이 되는건지 확실하게 알 수 없을까... 이클립스나 인텔리J 도움 없이 조인포인트를 확인할 수 있는 아주 간단한 방법이 있다는 것을 보고는 새삼 놀랐다. 내가 너무 모른다는 사실도 한몫했다.

또한 execution 포인트컷에서 사용하는 표현식을 분석한 표역시 대단하다는 생각밖에 들지 않는다. AOP 용어도 이해하고 대강의 사용법까지 익히더라도 항상 막막한 부분은 바로 표현식 작성이었다. 지금 읽은 부분에서는 아직 args나 this, type같은 건 등장하지 않았지만 아마 2부에서 더 자세하게 다룰 것 같다.

AOP 용어 정의를 거의 맨 뒤에서 설명하는 이럭 획기적인 방식으로도 AOP를 더 쉽고 알차게 학습 할 수 있다는 사실에 여러분도 놀랐것이다.  



top

  1. Favicon of http://lckymn.com BlogIcon Kevin 2010.05.18 23:44 PERM. MOD/DEL REPLY

    역시 트랜잭션 문제 해결하려면, AOP 를 고려해 보는게 좋겠죠?
    저도 최근에 DB Transaction 말고 파일시스템에서 파일 생성, 복사 등등에 관련된
    파일 트랜잭션 문제 해결하느라 AspectJ 사용해서
    FileTransactionManager 를 만들었습니다.

    파일 업로드 하다 실패하면, DB는 Transaction 지원되니,
    스프링에서 알아서 rollback 해 주는데, 파일 시스템에 저장된 파일은 해결이 안되서,
    일단 AOP로 파일 생성/복사 하는 메소드들만 처리해 주다가
    아예 @Transactional 처럼 annotation만 쓰면
    알아서 처리해주는 FileTransactionManager를 만들어 버린거죠.
    만들면서 또한번 '아! 역시 AspectJ 너무 좋아' 라는걸 느꼈습니다.

    Favicon of http://whiteship.me BlogIcon 기선 2010.05.19 12:05 PERM MOD/DEL

    넵. 트랜잭션 관리 코드가 서비스 계층으로 올라오면서 부터 지져분해지는 길의 시작이랄까요..그렇다고 DAO에 둘수는 없자나요ㅋ

    오홋.. 좋군요. 해당 애노테이션 붙어있는 메서드에 포인트컷 걸고 예외 발생했을 때 생성된 파일을 청소해주는 어드바이스 적용하셨나보군요.

    근데 ApsectJ는 조금 귀찮지 않으세요? 위버나 ajc를 사용해야 할텐데요. 하긴 ajc를 메이븐 빌드로 돌리면 별로 귀찮지 않을수도..

  2. Favicon of http://lckymn.com BlogIcon Kevin 2010.06.01 18:39 PERM. MOD/DEL REPLY

    네, 그렇게 되는거죠. :)
    거기에 nested transactions 관련된 부분 조금 신경쓴거 정도겠군요.
    트랜잭션 걸린 메소드 안에서 실행되는 다른 메소드에 트랜잭션이 겹겹이 걸렸다고 이미 지운 파일을 또 지우려고 하면 안돼잖아요. 거기다가 트랜잭션 전체가 끝날때까지 생성된 파일 정보를 가지고 있다가
    모든 트랜잭션이 전부 마무리 되었을때, 관리하에 있던 파일 정보 다 날리는거랑요.

    가끔 privileged aspect 를 쓸일이 있어서
    ajc 를 쓰고 있습니다만, 직접 컴파일 하는게 아니고
    Eclipse에서는 AJDT 와 m2eclipse 를 써서 별 불편없구요.
    빌드시에는 maven으로 aspectj-maven-plugin 써서 하구요.
    그래서 크게 귀찮은거 없는데...

    사실 불편이 없어야 하는데 하나가 좀... :)
    가끔 스프링의 @Transactional 적용한 메소드에
    weaving이 잘 안되는 경우가 있더군요.
    아무래도 aspectLibrary 적용하는 부분때문에 그런거 같습니다만.
    실험좀 해보니까, m2eclipse에서 full-build 를 해야
    이게 정상적으로 위빙이 되는데...

    m2eclipse와 AJDT eclipse-maven-plugin 중에
    어디가 문제인지는 모르겠지만, 아무튼 이게 가끔 제대로 안되더군요.
    수동 clean 빌드를 하면 full-build를 수행해서 정상적으로 되구요.

    해결하려고 이거저거 다 시도 해봤는데, clean말고 더 편한 해결책을
    못 찾았습니다. ㅠ_ㅠ 그냥 m2eclipse가 AJDT 이용해서
    컴파일 하면서 full-build 하면 될것 같은데... 이녀석이 말을 안 듣네요.
    아무튼 그래서 코딩하다가 실행해 보기 전에 clean을 해줘야 하는게
    좀 불편합니다. 그래서 이거 단축기 걸어놓고 쓰고 있어요.

    아... 그리고 그래서 Eclipse 버리기가 힘드네요.
    NetBeans 나 IntelliJ IDEA 다 써봤는데,
    이거 세세하게 제 마음대로 옵션을 바꾸려니 Eclipse 만큼 편한게 없네요.
    저는 foramming 부터 해서 단축키등등 이거저거 제가 편하게 쓸수 있게
    설정해서 쓰기 때문에 NetBeans 처음 사용해보고 불편해서 바로 삭제...ㅡ_ㅡ;

    암튼, 사실 생각보다 크게는 불편하지는 않구요.
    코딩 조금하고 실행해보고 이러지 않고 한참 하고나서 실행해 보니까요.
    (빌드전까지 보통 한번만 실행...^^; )
    실행전에 clean 한번 해주는걸로 해결하고 있습니다.
    중간에 자잘한거 테스트는 테스트 코드가 해주구요.

    아 근데, 쓰다보니 하나 떠오르는게 있네요. 아무래도 AJDT가 이해하게
    따로 aspectPath를 설정해 줘야 할것 같기도하고,
    이게 pom.xml에 되어 있긴 한데... 아무튼 지금은 잘 쓰고 있으니
    시간나면 한번 실험해 봐야겠네요.

    Favicon of http://whiteship.me BlogIcon 기선 2010.06.01 21:38 PERM MOD/DEL

    흠.. 인텔리J도 얼마든지 단축키를 맘대로 바꿔서 사용할 수 있어요. 요즘은 둘다 번갈아 가면서 쓰고 있긴 한데 그래도 인텔리J를 더 자주 쓰게 되네요.

    궁극적으로는 스프링 AOP에서 AspectJ로 넘어가면 좋긴하겠는데(프록시 내부 호출이나 런타임 오버헤드를 해결할 수 있으니) 기능이 너무 강력하단게 어떨땐 흠인것 같기도 하고.. AspectJ까지 사용할만큼 AOP를 즐겨 쓰진 못해서 걍 스프링 AOP로 만족하고 있어요 ㅋㅋ

Write a comment.


Toby's 스프링 AOP 등장 배경을 읽으며...



이번 기회에 스프링 AOP를 새로운 방식으로 학습하고 있다. 지금은 일단 스프링 AOP의 용어나 기능보다는 그 근본이 되는 ProxyFactoryBean의 유용함, 등장 배경을 이해하는데 초점을 맞추고 있다. 굉장히 중요한 부분이지만 도무지 레퍼런스에서는 이런 내용을 습득할 수 없었다. 빨간책(몇번째 시리즈인지는 까먹음. with Spring이던가..)에서는 언급이 되어 있지만 왠지 어렵고 잘 머리에 들어오지 않는다.

그 등장 배경을 이해하는 것은 결코 쉽지 않다. 그만큼 간단한 절차가 아니기 때문이다. 조금 길다 싶을 정도로 여러 단계의 정제 과정을 걸치게 된다. 그 과정 하나 하나에 문제, 해결책, 장점, 단점 또 그 단점을 극복하는 해결책 그 결과의 장점과 단점. 다시 또 그 단점을 극복하는 .. 이런식으로 꼬리에 꼬리를 물고 가다가 결국에 스프링 AOP의 핵심 요소들이 등장하게 된다. 

마침내 어드바이스, 포인트컷, 어드바이져, 포인트컷 표현식등 AOP 용어가 들려오더라도 전혀 당황스럽지 않다. 그 용어들의 느낌과 개념이 자연스럽게 이해된다. 어드바이스는 머다. 포인트컷은 머다. 라는 식으로 AOP 무식하게 학습했던 과거가 부끄럽게 느껴진다. 이런 학습방법으로 접근했다면 천천히 가는 것처럼 느껴졌겠지만 오히려 더 확실하게 개념을 익힐 수 있었을텐데 라는 생각이 많이 들었다.

이 부분에서 꼭 집중해서 살펴봐야 할 부분이 있다면 BeanPostProcessor가 언급된 부분이다. 그 부분을 자세히 읽으면 AOP 적용시 흔히 실수하는 상황을 잘 캐치할 수 있을 것이다. 보통 빈 설정을 잘못해서 AOP가 적용되지 않는 경우가 많은데 왜 그런지 그 이유와 원인을 이해할 수 있을 것이다.

이제 본격적으로 스프링 AOP에 대한 내용을 읽어야 하는데 시간이 늦어서 집에가서 봐야겠다..
그 작업을 target으로 집안청소 Advice와 퇴근 후 일정 Pointcut을 조합한 Advisor를 감지하여 프록시를 만들어 주는 DefaultAdvisorAutoProxyCreator를 설정해야겠다.
top

Write a comment.