| sitelink1 | |
|---|---|
| sitelink2 | |
| sitelink3 | |
| extra_vars6 |
올 초에 얘기했듯이 블로깅은 나에게 그다지 중요한 일이 아니었나보다. 지난 1월과 최근까지 나는 바뀐 생활패턴과 새로운 일 준비가 중요했고 개인적인 학습과 개발에 좀 더 시간을 쓰는 것이 공개적인 글을 쓰는 것보다 중요하다고 생각한 것 같다.
올해들어 나는 대부분의 학습시간을 새로운 Spring2.0의 기능들을 공부하고 적용해보고 앞으로 어떻게 활용할지 그 전략을 짜는데 보냈다. Spring2.0의 새로운 기능에는 다이나믹 언어지원처럼 완전히 새로운 기술이 있고 @AspectJ지원 AOP처럼 기존에 있는 기능이 달라진 것은 없지만 굉장히 편리하게 사용할 수 있도록 개선된 부분이 있다.
그 중 최근에 관심을 가지고 연구하고 있는 부분은 XML확장기능이다. Spring2.0은 DTD외에 schema기반의 XML설정파일을 작성할 수 있게 되었다. 덕분에 다양한 namesapce를 이용해서 확장된 XML tag을 사용해서 Spring의 bean config.이 가능해졌다.
Spring은 1.x에서도 몇번에 걸쳐서 config. xml을 좀 더 간편하게 작성할 수 있도록 그 사용법이 개선되었다. 하지만 여전히 하나의 bean을 설정하는데 <bean/>태그가 한나씩 필요한 것은 여전할 뿐더러 id, class, property등을 이용해서 설정하는 패턴도 동일하다.
Spring 2.0은 설정용 tag자체를 확장할 수 있는 기능을 만들었고 그것을 이용해서 이미 만들어진 schema기반의 다양한 설정태그들을 제공하고 있다. 심플하게 사용할 수 있는 <util:*/>부터 JEE기능의 설정을 쉽게 사용하게 해주는 <jee:*/>, AOP설정을 위한 <aop:*/>, 트랜잭션 어드바이스 설정을 위한 <tx:*/>, 툴을 위한 메타데이터 설정을 위한 <tool:*/> 그리고 global attribute를 이용해서 property설정을 손쉽게 해주는 p:* attribute가 있다.
Schema기반의 설정방식을 사용할 때 제일 장점은 뭘까.
가장 큰 장점은 설정파일이 단순해진다는 점. 설정파일의 종류에 따라 5-7개로 분산한다고 하더라고 애플리케이션의 규모가 커지면 설정파일이 점점 양이 많아지고 복잡해지는 것은 사실이다. 한심한 xml 설정방식을 가진 ejb나 struts에 비하면 양반이지만 어쨌든 id, class, property들이 가득찬 코드를 읽고 애플리케이션 구성을 이해하는 것은 쉽지 않다.
<bean />이라는 의미없는 태그보다는 <util:map/>, <jee:jndi />같은 것이 훨씬 빈의 특성을 이해하기 쉽다. 특히 애플리케이션의 핵심 로직이 담긴 POJO빈 외의 각종 인프라스트럭처 설정이나 엔터프라이즈 서비스등에 관련된 bean들은 태그레벨에서 구분되는 것이 훨씬 유리하다.
자주 사용되는 클래스를 이용한 빈이라면 class attribute를 제거하는 것 만으로도 훨씬 깔끔해질 수 있다.
아주 간단한 태그인 <util:properties />를 보자.
원래는 PropertiesFactoryBean을 이용해서 다음과 같이 설정해야한다.
<bean id=”properties” class=”org.springframework.beans.factory.config.PropertiesFactoryBean”>
<property name=”location” value=”xyz.properties” />
</bean>
이것을 하나의 고정된 클래스타입의 빈의 설정을 간단하게 만들 수 있는 AbstractSimpleBeanDefinitionParser을 이용해서 만든 PropertiesBeanDefinitionParser를 이용해서 만든 태그 덕에 다음과 같이 수정할 수 있다. 이걸 정의하는데 필요한 자바코드는 메소드2개에 7줄뿐이다.
<util:properties location=”xyz.properties” />
빈에 대한 이해와 가독성이 매우 높아지고 코드의 양이 대폭 줄어든다.
Custom tag을 사용하는 경우 가지는 또 한가지의 장점은 하나의 태그로 두개 이상의 빈을 설정할 수 있다는 것이다.
Spring 1.x에서 AOP를 이용해서 transaction을 설정하는 코드가 얼마나 복잡한지 경험해본 사람은 안다. 복사&붙이기로 쓰기는 하지만 무슨 일을 하는 어떤 빈이지도 모른채 ProxyFactoryBean, AutoProxyCreator,Advisor,Advice,… 따위를 사용한다. 어짜피 AOP를 깊이 알고 세밀하게 제어해서 쓸 것이 아니라면 Spring의 out-of-the-box 기능이라고 생각하고 간편하게 쓰는 것이 좋다.
Spring안에 있는 모든 기능은 다 bean의 형태로 등록이 되야하지만 그것이 주는 혼란함을 막을 수 있고 설정에 필요한 low-level bean이 직접 개발자들에게 노출되는 것을 막아줄 수 있다면 면에서 Spring의 기능에 대한 편리한 태그형태로 발전할 수 있는 기회를 제공한다.
Spring내에서 제공하는 기능을 사용하기 위한 tx, aop외에도 3rd-party 스프링 확장기능등을 간결한 custom tag을 통해서 제공한다면 매우 편리할 것이다.
엔터프라이즈 서비스와 같은 보조적인 기능들 말고 도메인의 특징에 따른 애플리케이션을 위한 전용 tag도 효과적으로 설계한다면 아주 깔끔하게 설정을 할 수 있을 것이다.
유연성은 좀 떨어지지만 컨벤션을 잘 활용해서 하나의 태그로 mvc를 위한 각종 resolver등의 기본 설정을 하게 한다거나 hibernate설정 등을 annotation기반의 aop등 을 이용한 모델클래스 검색기능들을 사용해서 session factory에 매번 모델등록을 안하도록 만든다거나 controller-servie-dao의 세트를 하나의 태그로 등록하게 한다거나.. 등등의 좋은 아이디어를 낸다면 Spring개발이 아주 간편해질 수 있는 길은 많이 있을 것이다.
특히 annotation을 활용한 bean설정기능은 Spring개발팀은 공식적으로 준비하고 있지는 않지만 원한다면 XML확장기능을 통해서 어렵지 않게 만들 수 있다. 물론 AOP의 도움도 필요하지만.
Spring2.0 Reference를 보면 Extensible XML Authoring항목에서 XML확장을 통한 custom tag을 어떻게 개발할 수 있는지 아주 잘 나와있다. 몇개의 tag를 만들어 보니 정말 쉽다. 그 들이는 최소한의 노력으로 오랜동만 편해질 수 있는 Spring2.0의 대표적인 매력이 바로 그것이다.