검색결과 리스트
글
[Spring Roo] (2) Roo를 사용하는 이유
그렇다면 Roo를 사용하는 이유는?
- 생산성이 뛰어나다
루를 사용하면 자바 개발자들이 복잡한 엔터프라이즈 애플리케이션을 수분 안에 가장 좋은 방식(Best Practice)으로
작성 할 수 있다. 자바를 수년동안 개발했던 개발자들은 자바의 생산성 문제를 인식하게 되는데, 새로운 프로젝트를
생성하고, 개발이 정상궤도에 오르기까지 수일이 걸리기 때문이다. 세계에서 가장 많이 사용되고 있으며, 많은 성숙
한 라이브러리를 제공하고, 뛰어난 성능과 광범위한 표준을 지원하는 매력적인 자바 플랫폼에, 루를 사용하여 뛰어
난 생산성까지 가미할 수가 있다.
생산성 외에도 팀으로 행동하며, 언젠간 다른 사람이 작성한 코드를 유지보수 할 수도 있기 때문에, 프로로서 아키텍
처 표준과 관례를 따르는 것도 중요하다. 루는 최적화된, "구성보다는 관례"를 따르는 방식으로 서로 다른 배경과
경험을 갖는 개발자들간의 차이도 극복하게 해준다.
- 업계 표준을 준수한다.
루는 자바5를 사용하는 개발자를 대상으로 설계되었기 때문에, 대부분이 익숙한 기술들이다
루 프로젝트가 사용하는 기술들은 Spring(Spring Framework, Spring Security, Spring Web Flow), Maven,
Java Server Pages, Java Persistence API(JPA, 하이버네이트 같은..), Tiles, AspectJ을 포함한다. 엔터프라이즈
자바 프로젝트에서 가장 많이 사용되는 기술들을 포함했다. 또한 애드온 방식을 사용해 구현되었기 때문에
프로젝트에 쉽게 다른 기술을 사용할 수 있다. 루는 이러한 기술들을 프로젝트에 매우 안정적이고, 점진적으로
추가하는 접근 방법을 취한다.
루는 새로운 프로젝트를 시작할 때, 단순한 JAR 를 빌드한다고 가정하기 때문에 어떠한 의존성도 갖지 않는다.
이후에 Persistence Provider가 필요할 때, JPA가 설치되고, JavaBean Validation 어노테이션을 필드에 사용할 때
해당 라이브러리가 프로젝트에 추가된다. Spring Security, Spring Web Flow 등 루가 지원하는 모든 기술들이
그러한 방식 으로 추가된다. 이것은 엔지니어링 트레이드오프 가 없게 한다는 루의 철학과 일맥상통하는 방식이다.
- 사용 및 배우기 쉽다.
루 개발자들은 Jef Raskin의 "The Human Interface" 라는 책에서 영감을 받아 루를 설계했다. 그는 사람들이
인터페이스에 자연스럽게 습관화 될 수 있도록 사용하기 쉽게 만들어져야 한다고 주장했다. 루는 이러한 사용자가
정말로 집중해야 할 점을 방해하지 않는 인터페이스 설계를 모티브로 하고 있다.
루는 텍스트 기반의 인터페이스로, 학습성(배우기 쉬운) vs 풍부성 vs 정보의 명료성이라는 트레이트오프를 가지고
있다. GUI는 위 세가지 요구사항을 모두 만족할 수 있지만, 루는 학습성과 풍부성에 좀더 초점을 맞추었다.
명료성은 루쉘이 직관적인 탭기반 완성시스템을 제공하여 극복했다. 명료성을 위해서, 이전에 완료된 명령에 기반
하여, 현재 명령의 대상을 결정하는 "문맥인식" 과 명령축약의 특징을 추가했다.
루의 학습성은 3가지 방식으로 이루어진다.
첫째, 업계표준의 자바 기술을 선택했고
둘째, 개입없이 루는 백그라운드에서 자동으로 동작하며,
셋째, 현재 프로젝트 상태에 기초하여 다음에 할것을 제안해주는 hint와 같은 명령을 제공한다.
그외에도 지능적인 탭완성 및 많은 문서와 리소스를 제공한다.
- 엔지니어링 트레이드 오프가 없다.
루 애플리케이션은 더 작은 배포크기를 갖으면, CPU 타임의 관점에서 더 빠르게 동작하고, 더 적은 메모리를
소비한다 또한 코드 어시스트, 디버깅, 프로파일링과 같은 IDE 서비스도 문제 없이 사용할 수 있도록 지원한다.
더 작은 배포크기는 루의 점진적인 의존성 추가 접근방법을 통해 이루어진다. 작은 JAR 파일로 시작하여 실제로
필요할 때만, 의존성을 추가한다. Roo 1.0.0 부터 루기반의 웹애플리케이션 WAR은 13Mb인데, 여기에는 스프링과
Spring JavaScript(Dojo내장), 하이버네이트, URL rewriting과 같은 더 작은 라이브러리가 포함되어 있다.
30Mb 이상의 WAR 공간을 절약하게 되고 이것은, 업로드와 컨테이너 시작을 더 빠르게 한다. 시작시간은, AspectJ의
뛰어난 컴파일 타임 위빙을 통해 이루어지는데, 싱글톤 객체들의 의존성 주입과 도메인 객체 advising 과 같은 진보된
요구사항을 만족할 수 있게한다. 또한 스프링 로딩시 전형적으로 생성되던 동적 프락시들이 더 이상 필요하지 않게된다.
동적 프락시 생성 오버헤드가 없기 때문에 시작이 더 빠르며, 동적프락시 흐름 제어를 위한 CPU 타임의 낭비가 없어
루 애플리케이션은 더 빠르게 동작한다. 프락시 객체를 사용하지 않는다는 것과 루의 런타임 컴포넌트가 없다는 것은
어떤 메모리 비용도 들지 않는다는 장점도 있다. 점점 더 엔터프라이즈 애플리케이션들이 가상화되고, 클라우드되는
환경에서 공유하드웨어에 대한 성능의 문제는 더욱더 큰 장점으로 작용 할 것이다.
루는 실용적이고, 유연하며, 유지보수 하기 쉬운 애플리케이션 아키텍처를 가지고 있다. DAO 레이어를 제거하고,
어노테이션 기반의 의존성 주입을 사용하여 엔티티에 자동으로 의존성을 주입하는데, 이 아키텍처는 극적으로 작성
해야할 Java 및 XML의 코드의 양을 줄이고, 개발 사이클과 리택토링 경험을 향상시킨다.
- Roo는 제거하기 쉽다.
요구사항의 변경, 더 좋은 대체툴의 등장, 납득할 수 없을 정도의 버그, 다른 소프트웨어의 버전을 지원하지 않는
문제 등 여러가지 이유로 인해 툴을 제거해야할 현실적인 가능성이 있다. 루는 런타임이 존재하지 않기 때문에
이러한 문제들은 루에서 상당수 해결된다. 루를 제거하기로 결정했다면, 단 몇분 만에 제거할 수 있다.
어떠한 코드도 작성할 필요 없으며, 큰 변경또한 발생하지 않는다. 단순히 이클립스에서 "push in refactor" 명령을
수행하고, 정규표현식 기반의 탐색/대체기능을 사용하면 된다.
'프레임웍로그 > Spring' 카테고리의 다른 글
| [Spring Roo] (4) Roo 설치하기 (0) | 2011.03.03 |
|---|---|
| [Spring Roo] (3) Roo 아키텍처 (0) | 2011.03.03 |
| [Spring Roo] (2) Roo를 사용하는 이유 (0) | 2011.03.03 |
| [Spring Roo] (1) Spring Roo란? (4) | 2011.03.03 |