개인적으로 궁금한점 ^^ 질문들어갑니다. ^^
윤희한
안영회
말씀을 들어보면 jdbcTemplate은 써보지 않으신 듯 한데, 기회가 되면 살펴보세요.
수십명 이상이 유지보수 하는 사이트라면 iBatis가 매력적일 수 있지만
소수가 유지보수 하는 경우라면 jdbcTemplate 이 강점이 더 많을 듯 하네요.
--
===============================================
Younghoe Ahn
SE Consulting Group/Consultant
Korea Spring User Group/President
email : yh...@itwise.co.kr, ahnyo...@gmail.com
c.p : +82-11-9034-5018
msn : youn...@korea.com
google : ahnyo...@gmail.com
ITwise Consulting, co. ltd.
#3030 ASEM Tower, 159-1, Samsung-dong,
Gangnam-gu, Seoul, 135-798, Korea
Tel : +82-2-6001-3046 Fax : +82-2-6001-3049
===============================================
박성철
회사에서는 iBatis를 쓰는 일이 많고요.
하이버네이트는 기존에 어떤 방식으로 작업하셨느냐에 따라서 쉬울 수도 있고 어려울 수도 있습니다.
우리나라 개발 현장에서는 예전 2 tier 시대의 개발 방식을 계속 쓰는 경우가 아직 많아서 SQL 무척 많이 활용하고 DAO
와 서비스는 거의 하는 일이 없는데 이런 방식이라면 아마도 하이버네이트 보다는 IBatis를 더 맞을지 모르겠습니다.
하지만 DB는 최대한 데이터 저장소 역할만 하도록 하고 로직을 Service나 Domain 객체에 두도록 작업하신다면 하이버네이
트가 전혀 어려울 일이 없다고 생각합니다. 오히려 업무 효과를 극대화 할 수 있지요.
솔직히 저는 iBatis를 좀 싫어하는 편입니다. jdbc template에 비해서 생산성이 높은 것도 아니고 확장도 어렵고
XML 디버깅도 짜증나는.. 더구나 다이나믹 쿼리도 그닥... jdbc template + 적당한 Query Object >
iBatis 라고 생각해요. ^^
Sewon Ann
jdbc template 쓰면 iBatis 쓰는 것 때문에 추가된 계층 때문에 코드를 뒤지고, XML 열면서 돌아다닐 필요가 없으니 다른 측면의 가독성에서는 나을 수도 있겠지만, 쿼리들이 많은 경우라면 iBatis 의 xml 형태 쿼리 관리도 그렇게 나쁘지 않다고 생각합니다. 그리고 한군데에서 작성된 쿼리들을 리뷰하기도 좋구요. 이런 내용은 모두 hibernate와 같은 제대로 된 ORM 을 사용하지 않는 다는 상황을 가정하고 있습니다.
딱히 그 외에는 jbdcTemplate 과의 비교에서는 그닥 장점을 발견하긴 힘드네요. 아주 원시적으로 JDBC 사용해서 ResultSet 들고와서 객체에 일일이 setValue 하던 것에 비하면 iBatis 는 정말 많은 장점을 가지고 있지만, jdbcTemplate 도 이런 것들을 잘 해 주니까요.
확장이 어렵다는 성철님 말씀엔 적극 동감합니다. 쿼리도 초기에 읽어놓고 시작해서 runtime 에 바꾸기도 안되고요. XML로 되어있으니 좀만 잘 하면 runtime 시에 바로 변경 query 적용할 수 있을 것 같기도 한데. dynamic query 도 쓰기 편하진 않더군요. query 일부분을 그냥 동적으로 고쳐버리는 것도 잘 안되는 것 같고요, 흐음.
그래도 Hibernate 를 모르는 개발자와 함께 SI 프로젝트를 진행한다면 저는 계속 iBatis (아니면 jdbcTemplate)를 사용할 것 같습니다. 저도 잘 모르고(빨리 공부해야 할텐데... ), Hibernate를 교육 할 여력도 없구요.
--
-------------------------------------------------------
Sewon Ann
Chief Staff Consultant @ SolutionLink
안영회
조금 첨언을 하자면, 항상 ' query 와 code가 섞여 있으면 가독성 측면에서 나쁜' 것은 아니라 생각합니다. DAO 구현체 안에는 SQL을 식별할 수 있는 statment 이름(id)과 주고 받는 객체/맵 정도만 표현되어 있고, 실제 SQL은 XML로 분할하는 방식이 좋을 수도 있죠. 하지만, 이클립스 사용에 익숙하다면 Ctrl+click을 통해 관련한 코드 사이를 이동하는 일은 무척 편안한 일입니다. 또한, 대부분의 DAO 구현체는 전체적으로 비슷한 모양을 띕니다. 스크롤하면서 보면 일종의 타이핑한 코드의 들여쓰기 모양이 일종의 패턴으로 보이죠. :) 처음 메소드를 구현해나갈 때는 패턴을 인지하지 못해 읽기에 불편해보일 수 있지만, '정보 시스템'의 경우 거의 유사한 코딩 패턴이 드러나고, 익숙해지면 편하게 느낄 수 있죠. 유지보수 하는 분과 협업할 때 확연히 느낄 수 있죠.
jdbcTemplate과 ibatis 둘 중 무엇이 절대적으로 좋다고 생각하진 않지만, 개인적으로는 jdbcTemplate을 선호합니다. 다음과 같은 이유 때문입니다.
1. IDE 코드 네비게이션에 좋다.
2. DAO 영역에서 Query 일부, 가령 select 문의 조건절을 자동 생성한다거나 하는 작업이 편해집니다.
3. DAO 로직에 분기가 포함되는 경우 SQL이 이를 모두 담기 보다 자바로 처리하면 상대적으로 쿼리가 단순해집니다.
특히, 점진적인 객체 지향 도입을 위해서는 3번 항목이 중요하다고 생각합니다. 변화는 하루 아침에 수용할 수 없고, 주변 개발자가 '그래 한번 해보자'하는 수준으로 조금씩 수용하도록 해야 한다고 생각합니다. 최근 iBatis를 쓰는 다수 사이트를 보면서 자바 클래스 만드는 일 자체에 거부감을 가진 개발자를 많이 보았습니다. OOP에 대한 기본적인 이해도 없이 다른 언어(주로 스크립트 언어나 4GL)를 쓰다가 자바를 배운 분들이죠.
복잡한 SQL/PL/SQL에서 로직을 자바 조건문으로, 여기서 다시 polymorphism 등으로 리팩토링 해 나가는 과정이 느닷 없이 Hibernate나 OOP, OOAD 등을 학습해서 하루 아침에 객체 지향 개발을 하겠다는 접근보다 현실적이라 생각합니다.
Sewon Ann
iBatis 의 지엽적인 문제로 한정해서 생각할 때, 2번과 3번은 정말 작성하는데 짜증을 유발하고 쓸데없이 긴 xml 과 sql의 혼합물 (이건 xml도 아니고 sql도 아녀~)을 만들어내게 하는 주범이었습니다. 아주 약~간 다른 쿼리 (예를 들자면 select 대상 column 이 조금 다르다거나, where 절이 조금 다른 ) 를 위해서 길다란 xml 뭉치를 copy & paste 할 경우엔 iBatis 를 버리고 싶지요.
박성철
했던 거 같지 않나요? ㅎㅎ
XML을 별도로 분리하는 것은 개발의 편의 보다는 개발이 끝난 후에 쿼리 최적화 단계에서 DBA들이 요구하더군요. 엉터리 쿼리
를 난발하는 개발자가 많아서 이렇게 한눈에 다 보이는 것이 필요한 듯 합니다.
그래서 저도 jdbc template를 쓰면서도 xml에 쿼리를 담아두고 꺼내쓰는 자그마한 코드를 만들어 씁니다.
jdbc template보다 ibatis가 더 좋은 것 중 1:1, 1:n 같은 관계를 처리할 때 편하다는 것도 있지요. 1:1
이야 jdbc template로 처리하기 어렵지 않지만 1:n은 머리 좀 써야...
lazy loading도 거론할 수 있겠지만 iBatis의 lazy loading은 실효성이 거의 없고...
cache는 springmodules의 cache를 활용하면 해결되죠.
On 4월28일, 오후6시25분, Sewon Ann <king...@gmail.com> wrote:
> 회장님의 글 중 2,3번에 동의합니다. 1번은 전적으로 동의하지는 않습니다. 그럼에도 불구하고 전 xml 로 따로 떨구어진 쿼리를
> 선호하기에 ^^;
>
> iBatis 의 지엽적인 문제로 한정해서 생각할 때, 2번과 3번은 정말 작성하는데 짜증을 유발하고 쓸데없이 긴 xml 과 sql의
> 혼합물 (이건 xml도 아니고 sql도 아녀~)을 만들어내게 하는 주범이었습니다. 아주 약~간 다른 쿼리 (예를 들자면 select 대상
> column 이 조금 다르다거나, where 절이 조금 다른 ) 를 위해서 길다란 xml 뭉치를 copy & paste 할 경우엔
> iBatis 를 버리고 싶지요.
>
> 2009/4/28 안영회 <ahnyoung...@gmail.com>
>
> > 두 분 의견 모두 적절하다 생각합니다.
>
> > 조금 첨언을 하자면, 항상 ' query 와 code가 섞여 있으면 가독성 측면에서 나쁜' 것은 아니라 생각합니다. DAO 구현체
> > 안에는 SQL을 식별할 수 있는 statment 이름(id)과 주고 받는 객체/맵 정도만 표현되어 있고, 실제 SQL은 XML로 분할하는
> > 방식이 좋을 수도 있죠. 하지만, 이클립스 사용에 익숙하다면 Ctrl+click을 통해 관련한 코드 사이를 이동하는 일은 무척 편안한
> > 일입니다. 또한, 대부분의 DAO 구현체는 전체적으로 비슷한 모양을 띕니다. 스크롤하면서 보면 일종의 타이핑한 코드의 들여쓰기 모양이
> > 일종의 패턴으로 보이죠. :) 처음 메소드를 구현해나갈 때는 패턴을 인지하지 못해 읽기에 불편해보일 수 있지만, '정보 시스템'의 경우
> > 거의 유사한 코딩 패턴이 드러나고, 익숙해지면 편하게 느낄 수 있죠. 유지보수 하는 분과 협업할 때 확연히 느낄 수 있죠.
>
> > jdbcTemplate과 ibatis 둘 중 무엇이 절대적으로 좋다고 생각하진 않지만, 개인적으로는 jdbcTemplate을
> > 선호합니다. 다음과 같은 이유 때문입니다.
>
> > 1. IDE 코드 네비게이션에 좋다.
> > 2. DAO 영역에서 Query 일부, 가령 select 문의 조건절을 자동 생성한다거나 하는 작업이 편해집니다.
> > 3. DAO 로직에 분기가 포함되는 경우 SQL이 이를 모두 담기 보다 자바로 처리하면 상대적으로 쿼리가 단순해집니다.
>
> > 특히, 점진적인 객체 지향 도입을 위해서는 3번 항목이 중요하다고 생각합니다. 변화는 하루 아침에 수용할 수 없고, 주변 개발자가
> > '그래 한번 해보자'하는 수준으로 조금씩 수용하도록 해야 한다고 생각합니다. 최근 iBatis를 쓰는 다수 사이트를 보면서 자바 클래스
> > 만드는 일 자체에 거부감을 가진 개발자를 많이 보았습니다. OOP에 대한 기본적인 이해도 없이 다른 언어(주로 스크립트 언어나 4GL)를
> > 쓰다가 자바를 배운 분들이죠.
>
> > 복잡한 *SQL/PL/SQL*에서 로직을 *자바 조건문*으로, 여기서 다시 *polymorphism *등으로 리팩토링 해 나가는
> > 과정이 느닷 없이 Hibernate나 OOP, OOAD 등을 학습해서 하루 아침에 객체 지향 개발을 하겠다는 접근보다 현실적이라
> > 생각합니다.
>
> > 2009년 4월 28일 (화) 오후 5:31, Sewon Ann <king...@gmail.com>님의 말:
> > email : yh...@itwise.co.kr, ahnyoung...@gmail.com
> > c.p : +82-11-9034-5018
> > msn : young...@korea.com
> > google : ahnyoung...@gmail.com
윤희한
분들의 의견을 간단하게 듣고자 메일 날린것이.. 이렇게 활성화가 되었네요..
많은분들의 글 정말 잘 읽었습니다.
모두다 일장 일단이 있는거같네요 ^^..
iBatis 가 학습에 걸리는 시간이 거의 안드는 반면에 하이버네이트는
학습에 시간을 약간 투자해야하네요..
하지만 iBatis보다 하이버네이트가 좀더 강력한 퍼시스턴트 툴인거같네요..
지금 새로 이직해서 아직 적응도 되질 않아 --;; 짬이 나질 않지만..
나중에 짬을내서 한번 공부해보렵니다.
여러분들의 고견 정말 잘들었습니다.
감사합니다.
-성철올림-
Sewon Ann
말씀하신 것과 같이 XML 별도 분리하는 jdbc template 이용이 기업에서 개발할 땐 더 좋을 것 같습니다. 그리고 1:n 관계나 lazy loading 같은 것을 깜빡했는데, 잘 지적해 주셨네요. 은근 이것 알고 쓰니 편하더라고요. 그러나 개발자 분들이 작성한 코드 열어보니 이것 잘 안쓰고 다 join 해서 얻어오시는 분들이 많더군요. 이러면 iBatis 쓰는 의미가 거~의 없을 듯 해요.
lazy loading 실효성에 대한 지적에 대한 내용을 알 수 있을까요? 1) 유용할 수 있으나 iBatis가 바보같이 동작해서 한계가 있는 것인지, 2) 애시당초 쓸 데가 없는 기능인지 말씀하신 내용 만으로는 잘 모르겠습니다. 1:n 상황에서 그렇게 쓸 데 없는 기능이라고 생각하지 않는데, 그렇다면 1) 번 케이스를 지적하신 것인가요? 그리고 언급하신 내용에 대한 링크가 있다면 부탁드려도 될까요?
예를 들자면 다음과 같은 시나리오에서는 lazy loading 이 있다면 유용할 수 있습니다. 무조건 join 하는 것 보다 깔끔하게 query 를 유지할 수 있고, 그렇다고 직급정보 얻어오는 부분마다 다시 query 날려서 코드가 지저분해지지 않고요. 근데 지난번 프로젝트에서 그닥 많이 쓰진 않았습니다. 흐
1. 사용자 객체를 가져온다.
2. 직급정보는 lazy loading 하도록 했다.
3. 직급정보를 필요로 하는 부분에서만 query 한번 더 날려서 (이건 iBatis가 알아서 함) 조회함.
lazy loading 시 문제는 serialization 이 잘 안되는 것 같더군요. tomcat 6.0 기본 설정이 session 을 disk 에 store 하는 것으로 되어 있는데, 매번 tomcat restart 할 때 마다 serialization 실패했다고 꽤 많은 에러메시지들을 봤습니다. lazy loading 설정을 하지 않은 녀석들은 잘 되었구요. 요건 나중에 상당한 문제를 일으킬 수 있을 것 같습니다.
박성철
> 아마 전에 광화문에서 뵈었을 때 였던 것 같기도 하네요 :)
아. 그 때도 얘기 했던가요? ㅎㅎ
저는 me2day에서 댓글 놀이 하면서 얘기 했던 것 말한 건데.. ^^
> 말씀하신 것과 같이 XML 별도 분리하는 jdbc template 이용이 기업에서 개발할 땐 더 좋을 것 같습니다. 그리고 1:n 관계나
> lazy loading 같은 것을 깜빡했는데, 잘 지적해 주셨네요. 은근 이것 알고 쓰니 편하더라고요. 그러나 개발자 분들이 작성한 코드
> 열어보니 이것 잘 안쓰고 다 join 해서 얻어오시는 분들이 많더군요. 이러면 iBatis 쓰는 의미가 거~의 없을 듯 해요.
그죠. 사람들이 iBatis를 쓰는 이유(그리고 hibernate를 안 쓰는 이유)는 기술적인 문제 보다도 그 동안 개발자들이
개발 방법이나 스타일을 바꾸지 않고도 뭔가 멋있고 편하게 개발할 수 있도록 해주기 때문이라고 생각합니다. 결국 iBatis를 사
용하는 것도 말씀하신 것 같은 join으로 도배하는 형식이 되버리죠.
만약 누군가가 iBatis를 SqlMap이 아닌 O-R Map에 준하는 방식으로 사용하고 있다면 그 사람은 아주 쉽게
Hibernate로 바꿔탈 수 있을 겁니다. (그리고 입이 찟어지게 좋아하겠죠)
> lazy loading 실효성에 대한 지적에 대한 내용을 알 수 있을까요? 1) 유용할 수 있으나 iBatis가 바보같이 동작해서 한계가
> 있는 것인지, 2) 애시당초 쓸 데가 없는 기능인지 말씀하신 내용 만으로는 잘 모르겠습니다. 1:n 상황에서 그렇게 쓸 데 없는
> 기능이라고 생각하지 않는데, 그렇다면 1) 번 케이스를 지적하신 것인가요? 그리고 언급하신 내용에 대한 링크가 있다면 부탁드려도 될까요?
제가 실효성이 없다고 한 것은 lazy loading 설정이 전역적이기 때문입니다. 전체적으로 lazy loading 기능을 켜
고 끌 수는 있지만 선택적으로 어떤 쿼리는 lazy loading을 사용하고 어떤 쿼리는 사용하지 않도록 할 수 없습니다. (적
어도 제가 아는 한도에서는... 제가 모르는 사이에 개선이 되었으면 모르겠지만요. 아마도 ibatis 3에서는 해결 되는 것으
로 압니다.)
뭐 전체를 lazy loading으로 처리하는 게 별 문제 없을 수도 있지만 말씀하신 것 같은 seriazation 문제도 그렇
고 데이터가 없는 경우에도 객체가 반환되는 문제 트렌젝션 스코프 문제 등 부가적인 문제들이 있지요.
무엇보다 앞에서 말한 것 같이 개발자들이 iBatis를 사용하는 방식을 보면 전혀 lazy loading(심지어 cache도)
을 할 수 있는 상황이 아닙니다. iBatis 같은 기술의 사용법을 교육하는 것 보다 이런 방식을 바꾸는 것이 훨씬 어렵더라고
요.
> lazy loading 시 문제는 serialization 이 잘 안되는 것 같더군요.
그죠. 도메인 객체가 serializable이라고 해도 proxy가 감싸고 있기 때문에 직렬화 할 수 없습니다. 결국 세션에 저
장하려면 DTO용 객체를 따로 만들어서 복사한 후에 세션에 넣어야 할 겁니다. 리모팅할 때는 XML로 marshalling 해
야 하고요.
세션이 아니라 ibatis 자체의 read/write cache도 lazy loading과 동시에 사용하지 못합니다. 이것도
serialization 문제 때문이지요.
> ...
>
> 추가 정보 »
lean...@gmail.com
제너2년차시면 저랑 같이 면접 보셨겠군요. (30분 시간주고 하던 pt ..-_-;) 뭐.. 결국엔 지금 회사를 선택했지
만...; 각설하고
hibernate를 쓰다가 이제서야 ibatis를 개발에 적용하는데
lazy나 cascading은 hibernate가 좀 더 쉬운 설정이 가능했고요.
(-lazy: hibernate에서 편리함때문인지 ... ibatis에서도 기본적으로 lazy기반으로 쿼리를 짜고 있습니다
join이 아닌..
-cascading: ibatis에서 cascading을 DB말고 sqlmap에서 설정 가능한가요...??)
(ibatis도 마찬가지이지만) hibernate가 모든 설정을 xml에서 옵션으로 처리하기에 디버깅할때 힘들었어요.
대신에 쿼리의 자동생성(?) 이라는 측면은 편하겠지만 이것이 단점이 될 수도 있겠지요.
초기의 학습비용은... hibernate가 훨씬 높았던것 같습니다 (개인적입니다)