자기 전에 잠깐 살펴본 Spring Roo

초인 블로거 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분도 안 되는데 글 쓰느라 한 시간도 넘게 지나갔네요. 글만 쓰면 왜 이렇게 머리 속이 하얘지는 지... 자겠습니다. -_-

by 박성철 | 2009/05/09 04:36 | 프로그래밍 이야기 | 트랙백(1) | 덧글(3)

트랙백 주소 : http://gyumee.egloos.com/tb/2373662
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from garangnip's .. at 2009/12/18 00:04

제목 : 꾸우의 생각
스프링 초보라 아직은 잘 모르겠지만, 대단한 기술. Roo...more

Commented by 김동현 at 2009/05/09 04:52
오늘 참 안자는 사람 많으세요 ㅎㅎ
Commented by 토비 at 2009/05/11 11:24
ROO에서는 선언적이고 전파될 수 있는 @Transactional이 적용된 로직코드를 도메인 오브젝트에 넣을 수 있습니다. 다른 도메인 오브젝트의 로직을 불러서 같은 tx로 묶을 수도 있죠. 로직이 고스란히 도메인객체로 옵니다.
RoR에서는 제가 아는한 tx처리(demarcation)를 컨트롤러에 넣습니다. 트랜잭션 스크립트가 도메인에 들어가지 않는다는 면에서(넣으려면 안될 것도 없지만 스프링의 aop를 이용한 tx 방식과는 확실한 차이가 나죠) DDD라고 보기는 힘듭니다. fat controller + active record 일 뿐이죠.

Commented by 박성철 at 2009/05/11 13:22
토비 : 예. RoR는 필요 없는(?) 단계를 줄였을 뿐이지 DDD라고는 할 수는 없습니다. 로직이 복잡해지면 별도 Helper 객체로 분리하도록 하기는 하지만 트랜젝션 스크립트에 기초하고 있지요. 그래서 그 부분이 Roo의 특징이라는 토비님의 의견에 전적으로 동의합니다. 그리고 RoR의 ActiveRecord가 그런면에서 완벽한 ActiveRecord로 보이지 않습니다.

그런데 제가 보기에 ROO의 DDD 지원 정도는 Spring과 큰 차이 없어보이는데요. 그러니까 한마디로 @Configurable를 통한 DDD 지원... 혹시 제가 놓치고 있는 부분이 있나요? ROO이기 때문에 더 DDD가 용이하다거나...

어서 ROO로 구현한 예제를 보고 싶네요.

:         :

:

비공개 덧글

◀ 이전 페이지다음 페이지 ▶