블로그 이미지
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  

Notice

'spring-roo-addon-facade'에 해당되는 글 2

  1. 2009.05.22 spring-roo-addon-facade 만들기(5)
  2. 2009.05.22 spring-roo-addon-facade idea(1)
2009.05.22 21:55 개발관련


Shell

Roo에서 shell 명령의 컨셉은 크게 두가지 입니다. Domain 클래스처럼, 한번 생성한후 차근차근 필드를 추가하여 관련 aspect를 만드는 방법과 Controller 클래스처럼 한방에 클래와 aspect모두 만드는 방법 입니다. 저는 Domain 클래스 생성 방법을 선택하겠습니다. 이유는 좀더 두 행위를 분리시켜서 생각할수 있고, 향후 DTO Assembler의 확장에도 편리할것 같아서 입니다.

한번의 shell 명령으로 인터페이스와 클래스 파일을 생성해야 합니다. shell 명령은 다음과 같이 두개의 클래스를 구현하면 됩니다. (classpath 에 interface 생성에 관한 부분이 있지만, shell명령으로 인터페이스를 생성하는 방법은 아직 제공하지 않고 있습니다. 이부분을 약간 더 살펴봐야 함.)

FacadeCommand - shell 명령 정의
FacadeOperations - 명령 실행시 생성되는 클래스 스크립트 정의


Annotation
어노테이션은 shell에서 생성된 자바파일에 이미 붙여서 나옵니다. 그러면 shell의 모니터링 기능에 의해서 @RooFacade를 감지하고 aspect 파일을 자동으로 생성하게 됩니다. 생성된 파일의 내용은 모든 Facade에서 기본적으로 제공해야할 메서드를 포함하고 있습니다.(이것이 무엇인지 아직 고민중에 있고, 지금 생각은 Controller에서 제공하는 기본인 list(),delete()등을 참조할 생각입니다.) 이 기능을 담당할 클래스는 3가지 입니다.

RooFacade - 어노테이션 선언
FacadeMetadata - 어노테이션으로 생성하는 스크립트 정의
FacadeMetadataProvider - 리스너에 메타데이터 제공
FacadeAnnotationValues - 어노테이션 정의 부분을 분리(설정이 많을때만, 아니면 FacadeMetadata에 포함해도 됨)


다음은?
위 내용까지는 별 무리없이 구현이 가능합니다만, 다음부터가 문제 입니다. DTO Assembler를 추가해야 하는데, 이것은 기존에 없던 전혀 다른 addon이 되야야 합니다. @RooFacadeDTO 로 자바 클레스를 생성해야하고, Facade의 return 객체를 DTO로 수정(Managed)되어야 합니다. 아마도 각각의 메서드에 @Roo 어노테이션을 붙일수 있게 해야 할듯 합니다. 그러면 좀 복잡해지는데, 나중에 시간을 한번 가져 봐야 겠습니다.

신고
posted by Max.
2009.05.22 21:50 개발관련


이전글에서 ROO의 현재 구조가 직접 쓰기에는 Layer적인 면이 약하다는 걸 알수 있습니다. ROO가 이렇게 한 이유는 아마도, 특정 Layer 형식을 고수하게 되면, 유연성을 침해하기 때문일 것입니다. 그래서 ROO가 제공하는 데모 프로그램도 appfuse처럼 Layer별로 표준 템플릿을 제공하는것이 아니라, 단순히 이렇게 사용이 가능하다는 예만  들어준 정도이지, 그것을 확장하여 어떤 프로젝트를 진행하기엔 무리가 있습니다.

그럼 왜 ROO는 appfuse처럼 템플릿형태의 예제를 제공하지 않았을까를 생각해 보면, ROO의 철학이라고 해야할까, 아무튼 강조하는것 중에 생산성 극대화와 유연성에 있습니다. 기존의 일반 대형 벤더들의 소스생성툴은 특정 형식의 Layout 구조 때문에 유연성에 많은 제약이 있습니다. 유연성을 제약하는 대신에 특화가 주는 장점을 취하고 있죠. 이런 특징들이 아마도 Application Framework의 장점이자 단점이 아닌가 합니다. ROO는 유연성을 살리기 위해 특정 Layout(아키텍쳐)을 추천하지 않고, 제공하지도 않습니다. 그것은 어디까지나 사용자 몫으로 남겨둔 셈이죠.

그러면, ROO 사용자는 그냥 그대로 Layer구분없이 아키텍처 없이 그대로 사용하면 되느냐? 안되겠죠. 프로젝트 규모가 작아서 그럴필요가 없다고 하더라도, 모든 프로그램은 살아있는 생명체처럼 자라나는 습성이 있기 때문에 아무생각없이 만들순 없습니다. 그럼 ROO는 그런것이 없기 때문에 사용자가 일부는 자동생성된 소스를 일부는 Layer구조에 필요한 소스를 생성하여 잘 조화를 시키야 합니다. 그런데, 잘 조화를 한다는게 오히려 기존 방법보다 더 짜증나는 작업일수 있습니다. 기존대로 Layer만들고 사용하는게 더 편하게 다가올수 있다는 말입니다.


그럼 ROO는 그냥 장난감에 불과하냐? A/F 역할도 아니고, 템플릿도 없고, Sehll로 생성된 소스코드는 실무에 사용하기 적합하지도 않습니다. 심지여 이런생각이 들때도 있습니다. '유연성을 포기하면, 특별한 Layout을 제공해줄수 있을텐데...ROO의 tagline을 수정하지 해야 하지 않을까' 하는 생각 말입니다.

그런데, 이렇게 생각해 봅시다. ROO에서 유연성을 제약하지 않았습니다. 그것은 순전히 사용자 몫으로 남겨둔 것이죠. 그럼 나는 ROO의 사용자인데, 내가 그 유연성을 제약하여 원하는것을 만들수 있다는 이야기가 됩니다. 유연성을 제약한다는건, 특정 Layout 형식을 사용자가 취하면 된다는것이죠. 이것은 그리 어려운게 아닙니다. 일반적으로 스프링사용자라면, 직접 그 Layout(아키텍처)를 나름대로 하거나, 다른 사람이 해 놓은거 가져다 쓰기도 했으니까요.

이것을 간단히 말하면, ROO는 사용자에게 A/F를 제공하는것이 아니라. A/F을 구성할수 있게 도와주는 Framework을 제공합니다. 즉, Helper Framework 라고 볼수 있습니다.



따라서 사용자는 자신의 환경에 맞게 유연성을 제약하고, 특정한 형식의 Layout을 만드는 시도을 해야 합니다. 'Spring ROO 와 DDP 구조 합성에 대한 기대' 글에서도 밝힌것처럼 ROO를 기준으로 자신만의 Layout 환경으로 변경할수 있어야 합니다. ROO는 쉽게 addon 프로젝트를 통해서 기능을 추가할수있게 구성되어 있습니다.(물론 나 같은 개발자에겐 쉬운일이 아니죠 ^^;;)

원한다면, 기존 addon 프로젝트를 수정하고, 자신이 원하는 addon 프로젝트를 추가하여, 자신의 환경에 맞는 Layout구조의 소스코드를 생성할수있도록 할수 있습니다. 아래 그림처럼 말이죠.

As Is

사용자 삽입 이미지

To Be
사용자 삽입 이미지



사용자 주도 ApplicationFramework! 이것이 진정으로 그들이 바라는 ROO 철학이 아닐까 합니다. 소스생성으로 생산성을 극대화하고, 사용자 정의 Layout으로 유연성을 확보하고, aspect로 복잡성을 좀더 줄여주고, 도메인에 집중할수 있게 하는것 말입니다. 그래서 ROO는 스프링철학과 상충하지 않고도 씨너지를 낼수 있는 좋은 프로젝트가 될것 같다는 예감이 듭니다.

최근에 spring-roo-addon-facade라는 모듈로 위 그림의 Facade에 해당하는 부분을 만들어 보려고 하고 있습니다. shell 명령으로 java파일을 생성하고, 어노테이션으로 aj를 생성하는데는 특별히 문제될게 없습니다. 그만큼 addon을 만드는게 어렵지 않은 작업입니다. 현재도 addon 모듈들이 추가되고 있는 상태입니다. 이렇게 빠르게 추가된다면, 조만간 위구조의 addon들이 모두 추가되지 않을까 하는 생각도 드네요.

신고
posted by Max.
prev 1 next

티스토리 툴바