ROO는 뭘까? DDD 프레임워크? 스프링기반 RAD 프레임워크? 글세.. 뭐라고 정의할지 좀 애매하게 느껴진다.

프레임워크란 어떤 패턴(스타일)의 애플리케이션의 틀을 만들어주고, 그 패턴을 빠르고 손쉽게 적용하기 위한 기반코드(라이브러리)와 API등을 제공하는 것을 말한다. 재밌는 것은 ROO에는 런타임시에 사용하는 라이브러리가 전혀 없다. 응? 이게 뭐람?

ROO는 벤 알렉스의 설명에서 볼 수 있듯이 스프링을 그냥 사용할 수 있게 해주지, 어떤 추상화된 레이어나 API, 수퍼클래스 등을 사용하도록 강제하지 않는다. 그런면에서 ROO의 공개가 스프링에 추상화된 프레임워크를 추가시키게 되어서 스프링의 자유로운 사용에 대해서 스프링 개발업체가 어떤 제약을 거는 듯한 느낌을 줄 수 있다는 나의 염려가 모두 사라져 버렸다.

그럼 ROO는 뭔가? 런타임 라이브러리도 없이, 그냥 스프링을 쓰게 해주는 것이라면 ROO는 프레임워크가 아닐까? 프레임워크 몇개 가져다가 붙여서 프레임워크 스택 만들어 놓고 새로운 프레임워크 만들었다고 우겨대는 그런 개념없는 짓을 했을 것 같지는 않은데 말이다.

 

ROO의 적용기술

ROO는 다음 4가지 기술의 결합이라고 볼 수 있다.

  • DSL 스타일의 코드 생성 기술
  • AspectJ의 Inter-type Declaration을 이용한 Mixin 기술
  • @Configurable을 이용한 투명한 DI 기술
  • JPA(Hibernate)를 이용한 투명한 퍼시스턴스 기술

 

코드 생성

ROO는 기본적으로 코드 생성 툴을 이용한다. 코드 생성 방법이야 뭐 특별할 것은 없다. 하지만 ROO의 코드 생성 방법은 기존의 코드생성 툴과는 다른 특성을 가지고 있다.

ROO는 런타임 라이브러리가 없다. 애플리케이션에 직접 포함되는 ROO 애노테이션이 있지만, 선언적으로 사용되는 것일 뿐이고 런타임시에 어떤 기능을 수행하는 것은 없다. 그렇게 보면 ROO는 프레임워크가 아니라 단지 코드 생성 툴이라고 볼 수도 있다. 하지만 ROO는 그런 툴의 수준을 넘어섰다고 볼 수 있다.

ROO 코드생성 방식의 특징은 두가지이다. 하나는 인터렉티브한 커맨드라인 방식을 지원하는 코드 생성 DSL을 가지고 있다는 것이다. XML을 사용하지 않은 것은 바로 인터렉티브한 사용을 손쉽게 하려는 의도가 아닌가 생각된다.

ROO의 샘플에 나와있는 Petclinic ROO버전을 만들 때 사용하는 코드생성 명령들은 다음과 같다. 이렇게 스크립트를 만들어서 한방에 실행하는 것도 가능하다. 좀 길어서 중간은 생략.

create project -topLevelPackage com.springsource.petclinic

install jpa -provider HIBERNATE -database HYPERSONIC_IN_MEMORY

new persistent class jpa -name ~.reference.PetType –testAutomatically


new persistent class jpa -name ~.domain.Owner -extends ~.domain.AbstractPerson -testAutomatically
new persistent class jpa -name ~.domain.VetSpecialty -testAutomatically

add field string -class ~.reference.PetType -fieldName type -notNull -sizeMax 30
add field string -class ~.reference.Specialty -fieldName name -notNull -sizeMax 30


install finder -class ~.domain.Pet -finderName findPetsByNameAndWeight
install finder -class ~.domain.Pet -finderName findPetsByOwner

new controller automatic -name ~.web.PetTypeController -formBackingObject ~.reference.PetType
new controller automatic -name ~.web.OwnerController -formBackingObject ~.domain.Owner
new controller automatic -name ~.web.PetController -formBackingObject ~.domain.Pet
new controller automatic -name ~.web.VetController -formBackingObject ~.domain.Vet

configure logging -level DEBUG -package WEB

 

자세히 보면 JPA스타일의 도메인 객체를 생성하고 validation 정보와 함께 필드를 추가하고, 검색용 finder를 정의하고, controller를 추가한 것이다. 부가적으로 JPA datasource와 logging 설정 정도가 추가적으로 있다.

ROO는 이런 코드 생성 언어를 이용해서 코드를 생성한다. 여기까지만 보면 특별할게 없다.

 

하지만 ROO의 코드 생성기술이 일반적인 코드생성 방식과 차별점을 가지는 것은 바로 두번째 기술과 결합되기 때문이다. 코드 생성툴의 한계는 무엇인가? 그것은 한번 생성하고 나서 그 코드에 손을 대기 시작하면 그 후에는 코드 생성 방식으로 더 이상 접근할 수 없다는 것이다. 계속 순수하게 코드모델정보->코드생성의 패턴을 유지하던가, 아니면 생성된 코드를 직접 손대서 사용하기 시작하면 더 이상 코드생성 툴을 사용하면 안된다. 사용자가 수정하거나 추가한 코드에 어떤 기능을 자동으로 추가하는 것은 매우 위험하기 때문이다.

하지만 ROO에는 이런 제약이 없다. ROO의 코드 생성방식은 개발이 어느 정도 진행된 이후에도 계속 사용이 가능하다. 필드를 넣고, validation조건을 바꾸고, 동작 옵션을 수정하고, 새로운 finder를 넣는 것도 가능하다. 기존 코드에 거의 영향을 주지 않고 이렇게 코드 생성방식을 지속할 수 있는 비결은 무엇인가? 그것은 Mixin 방식을 사용했기 때문이다.

 

Inter-type Declaration을 이용한 Mixin

Mixin은 자바개발자들에게는 생소한 개념이지만 Ruby와 같은 메타프로그래밍을 적극 사용하는 다이나믹 언어에서는 흔하게 사용되는 방식이다. Mixin은 abstract subclassing이라고도 한다.

여러 객체가 공유하는 동작이나 정보가 있다면 자바에서는 일반적으로 superclass를 만들어서 거기에 공통정보를 넣고 그것을 상속해서 수퍼클래스에 추상화 시킨 공통기능을 활용하게 한다. 자바는 단일 상속만 지원하기 때문에 그런 수퍼클래스를 이용한 방식에는 제약이 많다.

Mixin은 반대로 추상화된 서브클래싱 기법을 이용한다. 여러 객체에서 공통적으로 사용할 기능이 있으면 이를 모듈화 해서 이미 존재하는 클래스에 삽입시켜 버리는 것이다.

AOP에서 가장 어렵다고 생각하고, 가장 잘 사용되지 않는 기술은 Introduction, AspectJ용어로 하면 Inter-type Declaration은 이를 자바에서 가능하게 하는 기술이다.

 

Inter-type Declaration은 스태틱한 크로스컷팅(static crosscutting) 기술이라고도 한다. 일반적인 AOP의 적용방법은 다이나믹 한 방법으로 포인트컷에 정의된 조건에 맞는 객체들에게 한방에 적용이 된다. 반면에 Inter-type declaration은 이미 정의된 특정 타입에 스태틱하게 추가적인 애스팩트를 적용하는 기술이다. 보통 메소드나 필드의 액세스에 위빙되는 애스팩트와 달리 Inter-type declaration은 메소드나 필드, 타입정보, 애노테이션과 갈은 것을 추가하는 방식으로 동작한다. 그래서 원래 클래스에는 정의되어있지 않은 기능들이 마치 존재하는 것처럼 가능하게 하고, 그것을 조합해서 마치 Mixin처럼 자유롭게 추가 기능들이 삽입되는 방식을 사용할 수 있다.

 

ROO는 바로 이러한 Inter-type Declaration 방식을 사용한 코드를 생성해 낸다.

이 방식이 가지는 장점은 개발자가 만지는 코드는 매우 심플하고 순수한 도메인 로직만 나타나게 할 수 있으며 그 외의 JavaBean getter/setter, Entity 설정, Finder 메소드 등록, @Configurable의 적용 따위나 아니면 CRUD의 기본 동작을 모두 가능하게 하는 Controller의 기본 특성을 모두 감출 수가 있다는 것이다.

ROO는 Inter-type declaration을 통해서 이런 스프링의 기술적인 특성을 감추고 순수하고 부가적인(CRUD+Finder를 넘어선) 로직에만 집중할 수 있게 만들어 주는 것이다. 또한 Inter-type declaration은 사용자 코드와 분리가 되고 클래스 로딩 때나 별도의 컴파일시에 삽입이 되기 때문에 얼마든지 수정이 가능하다. 이것이 ROO가 개발중에 지속적으로 사용가능한 코드생성 방식을 적용할 수 있게 해주는 비결이다. 어떻게 보자면 코드 생성처럼 보이지만 매우 다이나믹하게 적용 가능한 설정을 만드는 것과 비슷하다고 볼 수 있다.

이미 다 알고 있는 기술이었는데, 이렇게 활용할 수 있다는 것이 내게는 무척 신선하게 다가왔다. "이렇게 쓸 줄은 몰랐지?" 하고 뒷통수를 한대 맞은 느낌이다.

 

ROO가 만든 코드를 보자. 다음은 Pet 도메인 클래스이다.

@Entity
@RooJavaBean
@RooToString
@RooEntity(finders = { "findPetsByNameAndWeight", "findPetsByOwner" })
public class Pet {

    @Size(max = 50)    private String contactEmails; 
    @NotNull    private Boolean sendReminders; 
    @NotNull    private String name; 
    @NotNull    @Min(0L)    private Float weight; 
    @ManyToOne    @JoinColumn    private Owner owner; 
    @ManyToOne     @JoinColumn    private PetType type;
}

단순한 필드와 애노테이션이 몇개 정의된 것이 전부지만, 사실은 JPA의 CRUD 모든 기능과 두개의 finder method, SpringMVC에서 사용할 수 있는 getter/setter의 정의와 @Configurable의 적용, 애노테이션을 이용한 validation이 모두 적용되어있다.

이것이 다음의 Controller와 결합해서 CRUD+Finder를 완벽하게 동작하는 기능을 수행하게 한다.

@RooWebScaffold(automaticallyMaintainView = true, formBackingObject = Pet.class)
@RequestMapping("/pet/**")
@Controller
public class PetController {
}

 

이 코드만으로 기존 Petclinic의 Pet부분에 대한 모든 기능이 동작한다. CRUD+Finder+Validation|+Getter/Setter 기능 외에 부가적인 도메인로직이 있다면 여기에 자유롭게 추가하면 된다.

 

이 코드를 보고 있자니 재작년에 Spring2.5를 최대한 적용해서 만들었던 OSAF가 생각이 난다. 그때 나는 Generics를 최대한 적용해서 위와 거의 비슷한 코드를 만들어서 애플리케이션을 개발할 수 있도록 적용한 적이 있다. 실제 프로젝트를 위해서 만든 것을 기선이가 공개용 OSAF1.0-M1으로 손을 봐서 내놓았다. OSAF를 사용한 CRUD개발 쑈를 보면 알겠지만 최소한의 선언만으로 위와 비슷한(finder는 없지만) 생산성을 가지는 코드를 만들 수 있었다. 오히려 ROO에는 없는 view 생성 tag도 개발해서 더 생산성을 높인게 특징이다.

하지만 그때 내가 사용했던 방법은 Generics를 이용한 GenericDao, GenericService, GenericController 방법이었다. GenericDao야 이제 흔하게 많이 사용되지만 Service와 Controller에 적용하는 건 사실 쉬운게 아니다. 2.5의 애노테이션 기반 SpringMVC의 덕을 많이 보긴 했지만.

그때 제일 아쉬웠던 것이 뭐냐면 결국 상속을 써야 했다는 것이다. Generic~ 클래스를 타입 파라메터를 정의하면서 상속해야 했던 것이다. 그래서 순수한 POJO 스타일로 만들 수 없었던 것이 제일 큰 아쉬움이다.

 

이에 반해서 ROO의 도메인 클래스(사실은 +CRUD repository+Finder+bean+validation)와 컨트롤러는 수퍼클래스가 없는 순수한 POJO이다. 거기에 AspectJ의 inter-type declaration을 활용한 옆차기(옆으로 치고 들어오기?)를 적용해서 모든 것을 다 가능하게 만든 것이다.

사실 알고 나서 보면 "이정도는 나도 만들겠다"라고 생각이 들지만, 처음 이런 생각을 하고 이렇게 효과적으로 응용했다는 것이 대단하다고 생각이 된다.

 

길어지니 다음 편으로…

Related posts:

  1. Spring ROO 대충대충 분석 (4) ROO의 미래와 의의
  2. Spring ROO 대충대충 분석 (1) 공개과정
  3. 테스트 할 수 없는 것을 테스트 하기. Spring ROO와 static method mocking.
  4. Spring ROO 대충대충 분석 (3) ROO의 Inter-type declaration
  5. TSE2006 넷째날 두번째 세션 – ROO
  6. Spring 3.0 (55) getBean(Class) 등장
  7. The Spring Experience 마지막날
  8. 뒤늦게 쓰는 SpringOne 2007 셋째날 후기
  9. S1A 2008 셋째날 – Spring JavaConfig
  10. The Spring Experience 둘째날
  11. Spring 3.0 (58) Static Class를 XML없이 빈으로 등록하기
  12. Spring 3.0 (8) Core 모듈의 선택 라이브러리 분석
  13. 미리 보는 Spring 3.0.1의 변경사항
  14. Spring 3.0 (46) Spring 3.0 M4 릴리스
  15. Spring 3.0 (52) 반쪽짜리 3.0 RC1 공개

Facebook comments:

to “Spring ROO 대충대충 분석 (2) ROO란 무엇인가?”

  1. 올커니.. introduction을 적극 활용한 것이었군요.

  2. ^^와~ 훌륭합니다~ 감동

  3. ambien without a rx ambien overdose much – side effects of stopping ambien cr

  4. I have not checked in here for a while since I thought it was getting boring, but the last few posts are great quality so I guess I will add you back to my daily bloglist. You deserve it my friend :)
    cheap chanel handbags http://cheapchanelhandbags.v5s7.com

  5. Peculiar article, just what I wanted to find.

  6. BV98ZA ebbujhqzcoix, [url=http://brjmmubnnvpn.com/]brjmmubnnvpn[/url], [link=http://hfygrymxrgzh.com/]hfygrymxrgzh[/link], http://usgvzriasexr.com/

  7. You really make it seem so easy with your presentation but I find this matter to be really something that I think I would never understand. It seems too complex and extremely broad for me. I’m looking forward for your next post, I will try to get the hang of it!

  8. Hi there my friends, how is everything? Here it is actually good YouTube video lessons collection. i enjoyed a lot. fruta planta reduce weight http://videochaterotica.org/index.php?do=/forum/thread/8/get-rid-of-excess-weight-and-cleanse-with-arkopharma-detox-4/

  9. 4UROxJ ixprluoqcvks, [url=http://sxkkhteiebye.com/]sxkkhteiebye[/url], [link=http://gsxetlftrtcy.com/]gsxetlftrtcy[/link], http://vwmzypidzzmr.com/

  10. WT4Xxz qukqyejvvxvy, [url=http://ibgisfaaqclu.com/]ibgisfaaqclu[/url], [link=http://qnsvztcnfnmr.com/]qnsvztcnfnmr[/link], http://yhzizwupjiiq.com/

  11. You really make it seem so easy with your presentation but I find this topic to be actually something that I think I would never understand. It seems too complex and very broad for me. I’m looking forward for your next post, I’ll try to get the hang of it!

  12. In the beginning Seemed final fantasy xiv gil http://www.u7buy.com/ffxiv/ are a real rip off simply because they were definitely therefore overpriced, products in the event that my very own companion gotten my family final fantasy xiv gil http://www.u7buy.com/ffxiv/ I used these individuals relating to when i absoulutly possess fell deeply in love with final fantasy xiv gil http://www.u7buy.com/ffxiv/!!!!!

  13. Spring ROO 대충대충 분석 (2) ROO란 무엇인가? » Toby’s Epril

  14. Pretty great post. I just stumbled upon your blog and wanted to say that I have truly enjoyed browsing your blog posts. After all I will be subscribing on your feed and I am hoping you write again very soon!

  15. gucci bags buy online Spring ROO 대충대충 분석 (2) ROO란 무엇인가? » Toby’s Epril

  16. gucci mane okay with me download Spring ROO 대충대충 분석 (2) ROO란 무엇인가? » Toby’s Epril

  17. aldo shoes free shipping Spring ROO 대충대충 분석 (2) ROO란 무엇인가? » Toby’s Epril

  18. best women’s running shoes Spring ROO 대충대충 분석 (2) ROO란 무엇인가? » Toby’s Epril

  19. nina shoes discount codes Spring ROO 대충대충 분석 (2) ROO란 무엇인가? » Toby’s Epril

  20. Did I read this correctly? Was Richard settling income and property on his daughter and her husband from Lord Stanley’s estate? The same Lord Stanley who betrayed him at Bosworth? If so, he had a real talent for making enemies! Unless there was some kind of cooperation with it on Stanley’s part for some reason, it’s no wonder Stanley didn’t support him!

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha