Spring ROO 대충대충 분석 (4) ROO의 미래와 의의
어제 잠들기 전에 ROO를 잠깐 본 것이지만 그 신선한 충격은 꽤 강하게 남아있었다. 스프링이나 하이버네이트, RoR등을 처음 봤을 때 못지 않은 감동이었다.
내가 생각하는 ROO의 특징과 의미는 이렇다.
- ROO는 스프링의 기능을 제한하지 않는다. 로우레벨의 스프링의 모든 기능을 다 활용할 수 있도록 열려있다. 그런면에서 프레임워크가 필연적으로 가져오는 추상화가 발생하지 않는다.
- ROO는 DDD스타일의 패턴을 지원한다. 투명한 영속성을 가지게 하는 JPA(Hibernate)와 로직을 도메인에 집중시키고 도메인을 트랜잭션 경계를 정의해준다. 구지 1:1로 대응이 될게 뻔한 Domain-Repository를 통합시켜주었다. 물론 여기에는 static한 방식으로 Finder메소드를 선언했다는 특징 또는 단점이 있다. 이는 아마도 RoR 스타일을 염두에 둔 것 같은데, 이에 대해서는 사실 좀 논란이 있을 수도 있다고 보여진다.
- ROO는 POJO domain, controller를 사용하게 해준다. 투명한 Test(test에도 inter-type declaration이 적용됐다)와 POJO스타일의 도메인객체 응용이 가능하게 만들었다. 이를 위해서 사용한 Inter-type declaration은 정말 멋진 아이디어이다. Adrian Colyer가 조언해 줬을까?
- ROO는 RAD개발을 가능하게 한다. 현재 ROO의 아키텍처 모델은 RoR과 비슷하다. 자바개발자라면 MVC+Helper 스타일의 구식 struts1 모델을 생각하면 된다. 하지만 훨씬 강력하다. 스프링의 모든 기능과 장점을 다 활용할 수 있기 때문이다. 원래 ROO는 mvc-service-domain-repository/finder 구조의 풀 DDD 아키텍처로 만들어졌다. 하지만 공개용으로 작업하면서 아마도 단순화된 구조로 접근하는 전략을 택한 것 같다.
ROO는 많은 aspect를 사용한다. 물론 ROO플러그인을 설치하면 filtering으로 _ROO_의 생성코드를 감출 수 있다. 또한 AJDT를 사용해서 IDE내에서 aspect가 적용된 코드를 직접 다룰 수 있다.
대충 분석이니 대충 여기서 마무리 해야겠다. 앞으로 ROO가 피드백을 통해서 발전하면서 어떤 모델이 나올지 기대 된다.
또한 ROO의 등장은 내게도 도전을 준다. 구지 ROO를 직접 사용하지 않더라도, ROO의 개발철학과 스타일을 따라서 ROO스타일의 프레임워크+툴을 만들어 쓸 수 있겠다는 자신감을 준다. 이제 개발을 새롭게 시작하는 스프링 3.0 기반 프레임워크는 ROO방식으로 만들 생각이다. 공개된 ROO와는 다르게 Full DDD 아키텍처를 사용할 생각이지만 어쨌든 같은 방식으로 접근이 가능하다고 생각된다. 기술적으로 도전할 거리도 많을 것 같다. 공부는 해봤지만 한번도 정식으로 적용해본 적이 없는 Inter-type declaration을 이용한 Mixin 방식도 더 깊이 연구해봐야겠다. Ruby의 module을 사용한 mixin 방식에 비해서 AJDT/AspectJ는 스태틱한 언어의 장점을 사용해서 Mixin된 코드의 네비게이션이나 에디팅이 가능하게 해주니 얼마나 좋은가.
한편으로는 Grails처럼 다이나믹 언어를 사용하고, 스프링과 하이버네이트를 백그라운드에 감추어서 접근하는 개발방법을, 한편으로는 직접적으로 스프링을 써서 개발하되 이런 반복적인 작업을 멋진 기술을 써서 감춰주어서 개발자들의 수고를 덜어주고 도메인 로직에 집중하게 하는 ROO 같은 것이 있다는 사실에 즐거움을 느낀다.
좋은 글 감사합니다.
전문 매거진에 투고해도 좋을 글을 이렇게 아낌없이 나누어 주시니, 고맙습니다 라는 말을 안하고 지나치기 죄송할 정도네요.
여러가지 생각이 교차하네요. 말씀하신 것 처럼 기발한 발상에는 감탄을… 하지만 너무 ROR을 따라하려고 한건 아닌지… 차라리 기존에 알려졌던 아키텍쳐를 유지했다면… Grails와 중복이 될 것 같기도…
좌우간… 이런 글을 하루만에 써내려간 일민님도 대단하십니다. 말씀하시는 것처럼 roo의 방식에 영감을 받은 새로운 시도들이 많이 있을 듯 하네요.
박성철/ ROO의 가장 핵심은 결국 DDD을 적용해서 도메인 객체 중심의 설계를 가능하게 한 점입니다. 그런면에서 RoR과 비슷하기도 하지만, 다르기도 하죠. RoR이나 Grails는 RAD개발이라는 수준에서 그치지만, ROO는 결국 스프링 기능의 전폭적인 활용이 가능하다는 면에서 중요한 차이가 있다고 봅니다. 물론 Grails에서도 스프링 기능을 사용하는 것이 가능하긴 하지만, 추상화된 레벨에서의 접근이라는 면에서 ROO와는 큰 차이가 있는 것이지요.
간만에 읽은 아주 즐거운 글~ 땡큐!!
물개/ 로고 만들어준다는 건 어찌 된거야. 물개는 잠수중?
자기전에 잠깐 보시고 이렇게 많은걸 파악하시다니 놀랄따름입니다. 좋은 정보 감사합니다.
대충 쓰셨다고 하셨는데, 내용은 대충 정도가 아닌데요…^^
멋진 분석 잘봤습니다. 역시 대단하십니다.
근데 의문이 가는게 하나 있는데요.
ROO_Plural, 이녀석의 존재말이죠.
토비님께서 테이블 이름을 말씀하셨는데…
ROO_Plural, 얘가 도대체 뭐하는데 쓰이나? View에서 복수형 이름을 뿌려주나? 봤더니 그건 아니고,
그럼 테이블 이름인가? 하고 봤더니 테이블은 이름이 단수형이더군요.
도대체 이녀석이 뭔지…
생각하다보니 복수형으로 된 객체이름을 써야할 경우가 많으니
나중에 필요할때 쓰려고 미리 만들어 놓은게 아닌가 하는 생각이 들긴합니다만…
아… 그나저나 ROO M1 버전, 이제 곧 나올것 같습니다.
오늘, 아 벌써 어제군요. 저녁때 벤과 스테판을 만났는데,
얘기하는거 보니 임박한 모양입니다.
kevin/ 대충 본거라 plural은 그냥 찍어서 생각한 건데 떠오르는 건 RoR의 그것 뿐이더군요.
작년 SpringOneAmerica에서 Ben Alex 만났을 때 ROO에 대해서 물어보니 무척 난감한 표정을 지으면서 아직 계획 중이라고만 했는데 이제 M1도 공개되고 하면 그 동안의 부담을 좀 덜게 되겠군요. 3년전 TSE에서 처음 ROO 발표를 들었을 때부터 생각하면 정말 오래기다렸습니다.
전 RoR에 대해 아는게 없어서…^^;;; (그건 이상하게 별로 관심이 안 가더라구요.)
대충 이거 저거 생각해봤는데… 뭐 결국 모르겠네요.
만났을때 그거 왜 넣은거냐고 물어볼껄 그랬어요…@_@;
막상 만나서는 ROO 얘긴 많이 안 해서…
스테판이 ROO 전부 벤이 생각해 낸거라고 말하는데,
“벤이 누구야?” 라고 물어봤습니다. 바로 앞에 있는데…ㅡ_ㅡ;
벤은 두번째 보는거였나 그랬는데, 저는 솔직히 스프링 배우고 사용하기 시작한지
얼마 안 되서 그당시 처음 만났을때는 누군지도 몰랐습니다.
그나저나 토비님 잠깐 보시고 분석이 참 자세해서 놀랐습니다.
역시 스프링을 제대로 오래 사용하신분이라 그런지…
저는 봐도 그냥 관심 가는 부분만 겉핥기 정도 밖에는…ㅡ_ㅡ;
그나마 최근에 AspectJ에 관심을 좀 가져서 그렇지 안그랬으면 보고
뭔 이상한게 이렇게 많아? 라고 했을지도 모르겠네요…@_@;
그나저나 3년… 정말 오래됐네요…^^;
오늘 친구한테 얘기 듣고 SpringSource.com 에 들어가서 Roo에 대해서 좀 보려고 했는데 사이트가 (Vmware에 인수되어서 인지) 다운되어서 낙심하고 있던 참에 이처럼 좋은 글을 찾게 되어서 기쁘네요~^^
좋은 글 올려주셔서 감사드립니다~~
우기/ 서버가 계속 다운 되었나보네요.
이건 또하나의 쓰레기일뿐…
W/ 논리도 없고 가치도 주지못하면서 자신이 누군지도 못밝히는 허접한 코멘트는 쓰레기라고 생각되지는 않나보죠.