블로그 이미지
Max.

calendar

          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            

Notice

'ROO'에 해당되는 글 53

  1. 2009.04.30 Spring ROO A1 테스트 하기(4)
  2. 2007.11.12 [DDP] ROO의 특징을 Demo에 적용해보기(4)
  3. 2007.11.06 ROO 관련 글 보는 재미...(11)
2009.04.30 20:30 개발관련

DDD관련 A/F 으로 관심이 모아졌던 ROO가 알파1 버전이 공개 되었습니다. 사실 어떤 사람은 이것을 많이 기다렸던 모양입니다. 저도 그런 사람중 하나 입니다. 오전에 소식을 접하자 마자 바로 다운 받아 설치하고 테스트까지 일사천리로 진행했죠. 제가 아직 기술적으로 아는게 없어서 대략 동작하는 모습과 소스코드 구성(구조나 분석이 아나라)등을 보니, 만만치 않습니다.

먼저 소스코드 구성은 aspectJ로 도배하다시피 되어 있습니다. 테스트까지 도배되어서 테스트 코드에 별다른 소스코드가 없습니다. ROO는 많은 부분이 자동생성되게 구성되어 있다는걸 아키텍처에서 확인할수 있었지만, 생각보다 소스코드 구성이 생소하게 느껴집니다. 예제에는 Spring3.0 과 Dojo기반의 Spring-JS까지 최신 모듈로 구성되어 있습니다. 아직, 잘자란 버그(인코딩문제)는 있는것 같습니다.

사용자 삽입 이미지
(소스코드 구성)

사용자 삽입 이미지

(실행화면)

아래 ROO를 설치하고 테스트 프로젝트를 생성하는 과정을 볼수 있습니다만, 귀찮다면, 여기 소스코드를 받아서 이클립스에 Maven 프로젝트로 Import 하여 바로 소스코드와 Tomcat을 이용해서 확인하실수 있습니다. (환경은 SDK1.5 + Eclipse3.4 + Maven2.0.7(m2eclipse) + Tomcat6.0 입니다.)


테스트하기는 비교적 쉽게 되어 있습니다.
1. ROO A1 버전을 다운 받는다.
2. 압축을 푼후 readme.txt에 'ROO INSTALLATION' 부분을 보고 환경을 설정한다.
3. readme.txt 에 'ROO SAMPLES' 부분을 보고 프로젝트를 생성한다.(Bootstrap을 제공한다는게 신기 합니다. @@;;)

저같은 길치가 단번에 설치하고 테스트가 가능한걸 보니, 상당히 쉽게 테스트가 가능한것 같습니다. ROO는 A/F 이슈 보다는 DDD가 가능한 A/F 이슈가 더 큰 이목이 아닐까 합니다. 당장 이걸로 뭘 어떻게 안되겠지만, 여러므로 지켜 볼만한 가치가 있는것 같습니다. 아마도 앞으로 이에 관련된 기술적인 이슈와 블로그 포스트를 찾아 볼수 있으리라 봅니다.

저의 첫 소감은, '생소한 구성이다. 그러나 구성에 흥미를 느낀다.' 입니다. (소스를 하나씩 열어보면 상당히 신기한게 많습니다. 천천히 들여다 봐야 겠습니다. ^^*)

신고

'개발관련' 카테고리의 다른 글

나와 더 가까이 - 아티스트 웨이  (2) 2009.05.04
거꾸로 시선  (0) 2009.04.30
Spring ROO A1 테스트 하기  (4) 2009.04.30
힘들때 찾아가면 좋을 새벽 꽃 도매시장  (2) 2009.04.29
의연  (2) 2009.04.28
SpringOne Europe 2009  (0) 2009.04.28
posted by Max.
TAG ROO, Spring
2007.11.12 10:20 이전글(~2009)
최근 찬욱님의 ROO Architecture review 라는 글을 보고 Demo에 적용해 보기로 했다. 해당글에서 눈에 띄는 것은 두가지가 있었다.

첫째 Repository에서 Finder의 분리이다. 어쩌면 이 당연한 현상을 왜 생각하지 못했는지 나 자신이 얼마나 생각없이 개발하는지 알수 있는 대목이다. 실무 개발시 주도메인은 상당히 많은 finder를 Repository에 만들수 밖에 없다. 그만큼 각양각색의 조건들이 포함된 Select가 많이 있기 때문에 그렇다. 이 개념은 당장 도입해도 좋을 개념이다. 사실 최근 프로젝트에서 엄청나게 많은 finder를 넣은 Repository를 만들었다. Repository라고 부르기에도 민망할정도로....

둘째는 DTO assembler라는 것이다. 이것은 DO를 DTO로 값을 복사해주는 역할을 한다. 이것 자체의 구현 역시 어렵지 않다. 그러나 이것이 주는 의미는 ROO에서 의미하는 바가 크다. 보통 우리가 말하는 Service Layer 에서 DO를 쓴다. 이것은 DTO에서 내부적(?)으로 가져다 쓰는 구조 이다. 즉 모든(3Tier)계층에서 DO를 쓴다. 그러나 ROO에서는 DO를 쓰지 않는다. 엄격히 Domain Layer 아래로 격리시킨다. 따라서 Biz Layer(이것이 다른이름으로 불리던 어쩌던 간에 비지니스로직을 수행하는층을말함)에서는 DTO 를 쓴다. 핵심은 여기서 나온다. 이렇게 DTO를 씀으로써 번거러움이 가중되고, 더 세분화 함(Finder등)으로써 늘어나는 클래스를 어떻게 할것인가?
ROO에서는 이런것들을 Code Generation 으로 해결한다. Finder를 수동(?)으로 구현하거나 DTO를 Dozer를 써서 이것을 수동(?)으로 구현하는것은 기존에 했던 방법보다 손이 많이 가며 그리큰 매력을 느끼기 힘들다.

그러나 이들을 자동화해 버린다면? DTO, Finder,XML 심지여 TestCase까지 자동으로 생성해 준다면? 멋지다. 이것이 ROO의 가장큰 특징이 아닐까 한다. CG(Code Generation)에 대해서는 아직 아는바가 없다. Toby님 글에 '아주 정교하게 구현되어 있다'라는 언급만 나왔을뿐 뭘 어떻게 하는지 알기 힘들다. ROO가 언제 공개될지, 아니면 영원히 오픈 안될수도 있지만, 지속적으로 주시해볼 필요가 있다.

일단 두가지 특징을 수동(?)으로 만들어 Demo에 적용해 보았다. 그냥 그저 그렇다 ㅡㅡ;;
역시 자동화가 Key 인것 같다. Maven과 eclipse에 대한 기능을 잘 익혀두어야 한다. ROO가 나올때를 대비해서 말이다.

(그나 저나 앞으로 ROO에 대한 소식을 들을만한곳이 없다. 어디서 소식을 들어야 할지...Toby님도 잠적하시고...-,.-a )
신고
posted by Max.
2007.11.06 09:53 이전글(~2009)

저마다 생각하는 Best Practice가 있을 것이다.
Spring을 이용해서 자신만의 Best 아키텍처를 지속적으로 발전시키는건 또하나의 재미있는 일이다.
이리 저리 무언가 꺼리를 생각하던중 눈에 들어오는 것이 생겼다.
ROO.....
ROO는 과거 토비님이 TSE2006을 다녀와서 블로그 언급한적(1),(2)이 있다.
대략 '나중에 공개되니 그때한번 보자' 라는 생각으로 정리 되었던 기억이 난다.
Raible에서도 이런 저런 댓글이 많지만 여전히 나에겐 매력적인 놈으로 보인다.

최근 관련해서 찬욱님이 의욕차게 글을 올려주고 있다.
ROO에 대한 스터디 내용인데 재미 있고, 실무에 응용 할만한 내용도 있다.
핑계꺼리만 찾는 나보다 실천하는 그의 노력과 열정이 부럽기만 하다.

이쯤 되면.... 나도 시간을 만들어서라도 관련 코드를 만들어 봐야 할텐데...


신고
posted by Max.
TAG ddd, ROO