생각하고 나누고 공감하기...

초인 블로거 Toby님의 친절한 설명 시리즈(1,2,3,4)와 기선님의 설치 및 예제 실행법에 힘입어 저도 자기 전에 (사실 아직 잠을 안 잤으니 자기 전일지 아애 잠을 안 잘지는 잘 모르겠네요) 잠깐 Roo를 맛 봤습니다.

사실 Roo라는 것도 한 달 전 쯤 Toby님에게 우연히 듣게 되었고 몇가지 블로그 글 읽으면서 코끼리 다리 만지듯 이런 저런 상상만 하고 있었는데 이렇게 발표가 되니 반갑기도 하고 당황스럽기도 합니다.

일단 열어 본 첫 인상은 이 Roo가 그 Roo 맞나 싶습니다. 얘기 듣던 것과 구조가 많이 달라서요. 알렉스 아저씨가 지난 3년 동안 발전시킨 생각을 반영해서 원래 Roo와 다른 공개용 Roo를 새로 만든 건 아닌지 모르겠네요. (제가 좀 넘겨 짚기 대왕입니다. -_-);

자세한 것은 Toby님 글을 보면 될 것이고... Toby님 글을 보고 궁금했던 것만 따로 좀 살펴 보았습니다.

우선 Domain에 Repository의 로직을 통합했는데 이건 정확히 Active Record Pattern으로 보입니다. 사실 RoR의 ActiveRecord가 진짜 ActiveRecord는 아닌 것 같다고 생각하고 있었는데... (물론 큰 의미는 없는 구분입니다만) Roo에서 사전적인 구현을 보게 되었네요.

제가 Toby님 글에 답글로 너무 RoR과 비슷하게 만들려고 한 것 아니냐고 쓴 것에 대해 Toby님께서 Roo는 DDD를 구현했다는 점에서 다르다고 하셨는데 DDD가 가능하다는 것은 알겠지만 예제는 자동 생성된 CRUD와 Finder 몇개 외의 DDD의 맛을 볼 수 있는 부분은 아직 없는 듯 합니다. 앞으로 예제가 보완되기를 기대합니다.

다음은 Controller 부분을 봤습니다.

자동 생성된 컨트롤러는 아무런 로직도 없습니다.

@RooWebScaffold(automaticallyMaintainView = true, formBackingObject = PetType.class)
@RequestMapping("/pettype/**")
@Controller
public class PetTypeController {
}

그래서 믹스인되는 AspectJ 파일을 보니 여러가지가 메소드가 정의되어 있네요.

• create() : RequestMapping(value = "pettype", method = RequestMethod.POST) 
  
• createForm() : RequestMapping(value = "pettype/form", method = RequestMethod.GET)
  
• show() : RequestMapping(value = "pettype/{id}", method = RequestMethod.GET)   
  
• list() : RequestMapping(value = "pettype/{id}", method = RequestMethod.GET)   
  
• update() : RequestMapping(method = RequestMethod.PUT)   
  
• updateForm() : RequestMapping(value = "pettype/{id}/form", method = RequestMethod.GET)   
  
• delete() : RequestMapping(value = "pettype/{id}", method = RequestMethod.DELETE)   
  

REST 방식입니다. Parameter가 아닌 PathInfo에서 id를 받고 있는 것도 그렇고 create에 POST, update에 PUT, delete에 DELETE HTTP Method를 사용하는 것도 그렇고 말이죠.
그러니 당연히 spring 3를 쓰고 있다는 거죠.

발표가 안 될 것 같았던 Roo가 Spring 3의 마일스톤 버전이 공개되는 이 시점에 갑자기 발표되는 것이 어떤 의미가 있는 듯 합니다. 마치 개발하기 시작한지 얼마 안 된 것 같은 모습으로 말이죠.

그리고 아직 Presentation 단에는 별다른 기술이 적용되지 않았습니다. 그냥 담백하게 jstl로 갈지, 아니면 다른 생산성 높은 기술이 적용될지 궁금합니다. 저는 웹 어플리케이션의 생산성 향상의 키는 Presentation 단에 있다고 생각합니다. 재사용성을 높이고 변경에 빨리 대응할 수 있는 기술이 적용되기를 기대해봅니다.

가장 감동 받은 부분은 domain에 static method로 믹스인 되는 finder 메소드입니다.
사실 제가 작년에 spring jdbc를 가지고 active record를 구현하려고 시도했었습니다. 한참 진행하다 바쁘고 만들어봤자 쓸 사람도 없고 (회사가 망했습니다. -_-) 해서 그냥 포기했는데요. 그 때 finder를 domain의 static method로 넣고 싶었지만 generic으로는 방법이 없더라고요.

그냥 범용 finder를 만들고 domain class를 parameter로 넘기거나

MyDomain domain = finder.findById(MyDomain.class, 100);

Generic을 사용해서 finder를 domain과 분리하여 따로 만드는 수 밖에 없는 것 같더군요.

MyDomain domain = new Finder<MyDomain>().findById(100);

제가 원하던 방식은 이런 건데 말이죠.

MyDomain domain = MyDomain.findById(100);

그런데 Roo는 AOP로 간단히(?) 구현했네요. 감동이 쓰나미 처럼 몰려옵니다. (다만 Roo의 XXX_Finder.aj에 있는 Finder 메소드들은 Domain 객체를 찾아주지는 않고 JPA Query 객체를 반환합니다. 유연성 때문인지... 반면에 XXX_Entity.aj의 FindXXX 메소드들은 도메인 객체를 직접 읽어서 반환합니다. )

솔직히 지금까지 Mixin이 복잡도를 너무 높이는 것 아니냐는 생각을 가지고 있었습니다. 그런데, 이미 객체지향기술도 한물갔다는 소리가 나오고있는 상황이고... 그동안 트랜젝션 처리나 로깅 정도로만 생각했던 AOP가 어떻게 변화를 줄 수 있는지 실감이 나네요.
 
우짰든 살펴보니 아직 개발 초기단계인 듯 하고 앞으로 계속 주목해야 할 것 같습니다. 완성되면 어떨지 몰라도 아직은 광고처럼 대단해 보이지는 않네요. Toby님 말씀처럼 DDD 대응이라는 점과 Spring을 그대로 사용할 수 있다는 부분이 경쟁 기술에 비해서 나은 점으로 보입니다.

살펴본 것은 30분도 안 되는데 글 쓰느라 한 시간도 넘게 지나갔네요. 글만 쓰면 왜 이렇게 머리 속이 하얘지는 지... 자겠습니다. -_-