struts spring 비교

 

출처 : http://levin01.tistory.com/1513

 

Struts에서 Spring으로의 이주 가이드.

당신은 이 글을 통해 Struts애플리케이션에서 Spring MVC애플리케이션으로 변형하는 방법뿐 아니라 두 프레임워크사이의 논리적인 맵핑과 Struts개념을 Spring MVC개념에 관련시키는 수단을 배울것이다.

사실 Struts프레임워크는 기술발전이나 채택이 감소하기 시작하고 있다고 몇몇 사람들이 제기한다. 사실 Struts의 책임 개발자인 Craig McClanahan또한 Struts사용자에게 새로운 웹 프레임워크로의 이전을 권하고 있는 상황이다.

반면에 J2EE웹 공간에서, Spring MVC는 꾸준한 채택과 자바 개발자의 주의를 끌고 있다.

가장 인기있는 Spring프레임워크는 잘 디자인되었으며, 잘 만들어졌고, 혁신적이다.

그래서 많은 Struts사용자는 Struts를 위한 대체 프레임워크처럼 Spring을 MVC를 사용할것이다.

이 글은 Struts애플리케이션을 Spring MVC로 이전하길 원하는 개발자들을 도와준다.

그리고 다음의 두가지 핵심부분으로 나누어져있다.

1. Struts와 Spring MVC프레임워크의 기본 개념사이의 논리적인 맵핑.
2. 이전 대체물을 위한 기본적인 추천사항들.

논리적인 맵핑 : 다른 프레임워크간의 유사함.

Struts와 Spring은 MVC패턴 구현에서 본질적으로 유사하다.

둘다 핵심 J2EE컴포넌트인 Servlet과 JSP에 기반한 모델2 타입의 개발방식을 주로 할려는 경향이 있다.

Struts에 친숙한 개발자는 하나의 프레임워크에서 다른것으로 개념적으로 쉽게 이주할수 있다.

두가지 프레임워크 모두 View, Controller, Model의 역활을 제공하는 컴포넌트를 명백하게 서술하고 있다.

유사성은 구현레벨에서 멈춘다.

Struts디자인은 각각의 사용자지정 action이 Struts Action컴포넌트의 구조적인 상속이 된다는것을 의미하는 견고한 상속에 기반을 둔다.

Spring컨트롤러는 인터페이스이기 때문에, 어떠한 컴포넌트도 컨트롤러의 역활을 수행할수 있다.

이것은 애플리케이션 디자이너에게 컴포넌트 디자인의 좀더 나은 유연함을 제공한다.

프레임워크 컴포넌트 레벨에서 Struts는

Form Beans (정적이거나 동적인), Actions, Action Mappings, Action Forwards, 그리고 Request Processors와 같은 Struts 특유의 객체 사용을 요구한다.

Spring MVC는 주요한 컴포넌트가 인터페이스처럼 정의된것처럼 좀더 유연하다.

Struts는 오직 웹 프레임워크일 뿐이다.

Struts는 애플리케이션 개발에서 오직 presentation계층에만 할당한다.

반면에 Spring MVC는 비지니스 컴포넌트에다가 Spring 기업용 개발의 다른 부분을 관리하는 Spring 프레임워크의 다른 부분과 완벽하게 통합되는 Spring프레임워크의 주요한 부분일뿐이다.

이제 좀더 상세하게 프레임워크 컴포넌트를 보자.

Struts Actions는 대략 Spring Controllers이다.

Struts에서 Action은 프레임워크의 핵심 "processing"객체이다.

그것들은 MVC패턴에서 컨트롤러의 역활을 수행한다.

Struts Actions의 Spring이 가진 대안은 Controller인터페이스이다.

반면에 Controller는 Spring에서 사용자 입력을 처리하고 View컴포넌트로 전달한다.

Struts Actions과 Spring Controller사이의 가장 명백한 차이점은

Actions는 추상 클래스이고 Controllers는 인터페이스라는 것이다.

Spring MVC 컨트롤러처럼 설정되기 위해서, 객체는 오직 다음의 메소드를 구현할 필요가 있을것이다.

 

ModelAndViewhandle Request(HttpServletRequest request, HttpServletResponse response) throws Exception;

이 디자인(인터페이스에 의한 디자인)은 애플리케이션과 프레임워크간의 커플링을 최소화한다.

또한 이것은 Controllers의 디자인에서 구조적으로 좀더 유연성을 제공한다.

이것을 염두해 두고, Struts에서 Spring으로의 가장 간단한 중계역활을 하는 이전(transition) 단계는 Action을 다시 쓰는 것이다.

그래서 그것들은 Controller인터페이스를 구현하고 존재하는 코드를 재사용하는것이다.

이것은 애플리케이션 작동을 유지하는 동안 모든 Struts의존성의 제거를 증가시키는것을 허용한다.

Spring은 다른 Action대체물도 제공한다.

많은 수의 프레임워크가 제공하는 Controller구현물은 가장 공통적인 웹애플리케이션 작업에 대응된다.

몇몇 제공되는 Controller는 당신이 친숙한 Struts Action에 좀더 특성화된 것에 대응된다.

예를 들어, 당신이 DispatchActions을 사용한다면, MultiActionControllers와 좀더 잘 다듬어진 AbstractWizardFormControllers가 도움을 줄것이다.

다른 Controller구현문은 Spring MVC에 딸려나온다.

Action Forms이 없다.

Spring프레임워크내에서 가장 크고 가장 긍정적인 차이점중에 하나는 특성화된 ActionForm객체가 없다는 것이다.

프레임워크는 HTTP폼 값을 직접적으로 POJO에 바인딩하는것을 지원한다.

이 기능은 생성하고 유지할 클래스의 수를 제한하여 애플리케이션 유지관리를 단순화한다.

이 경우, 이전(migration)은 폼빈즈를 삭제하고 직접적으로 도메인 객체를 사용하는것을 의미한다.

어쨌든, 이것은 당신이 폼입력과 도메인 객체간의 맵핑처럼 Form Bean객체를 사용할수 있다면 필수단계는 아니다.

Spring MVC에서, AbstractFormController구현물을 확장하는 특수한 목적의 Controllers는 폼을 지지하는 빈즈를 지원한다.

AbstractFormController의 사용자지정 하위클래스는 폼객체처럼 폼을 지지하는(Command) Beans를 사용한다.

다시 말해, 이러한 빈즈를 정의하는 요구사항은 없다.

Command객체는 java.lang.Object의 어떠한 하위클래스도 될수 있다.

ActionForwards vs. ModelAndView

Struts ActionMapping에서, 객체는 표현자원(Actions, JSPs, Tiles, HTML 파일들 등등.)을 가리킨다.

Spring MVC에서 ActionMapping에 대해 가장 가까운 의미의 컴포넌트는 ModelAndView인터페이스이다.

Spring Controllers는 사용자에 의해 구현될수 있는것처럼 ModelAndView인터페이스의 구현물을 반환한다.

또는 당신이 원한다면 Spring MVC에 의해 제공되는 ModelAndView구현물을 사용할수도 있다.

내포하는 이름처럼, ModelAndView객체는 Model과 View컴포넌트를 가진다.

Model컴포넌트는 View컴포넌트를 통해 표시되기 위한 비지니스 객체를 포함한다.
시나리오에 따르면, ModelAndView구현물은 포함된 어떠한 Model컴포넌트를 가지지 않는다.

그것들은 아마도 실질적인 View컴포넌트(JSP, XSLT, Tiles, HTML, XML, 등등)의 몇몇 형태로 이끌것이다.

Controller구현물에서 처럼, 나는 Spring MVC가 제공하는 Model의 구현물과 View인터페이스 그리고 View해석자(Resolver)를 조사하는것을 강력히 권한다.

사용자지정 JSP 태그들

Spring MVC는 표준 JSP태그 라이브러리의 의미있는 힘을 신뢰한다.

Struts와는 달리, Spring MVC는 HTML, logic, 또는 bean처리를 위한 분리된 태그 라이브러리를 제공하지 않는다.

이것은 Command객체에서 Web form으로의 바인딩을 가능하게 하는 작은 태그라이브러리만을 제공한다.

당신은 다른 모든 작업을 위해 표준적인 템플릿 라이브러리(JSTL)를 사용할것이다.

유효성체크(Validation)

만약 당신이 Struts의 Commons Validator을 사용한다면, 당신은 Spring내에서 완벽하게 재사용할수 있을것이다.

Spring 1.2는 Commons기반 유효성체크를 지원하지 않지만

Spring MVC의 "sandbox"버전은 Commons Validator마크업 (validator.xml 과 validation-rules.xml)으로 쓰여진 유효성체크 정의의 재사용을 지원한다.

유효성체크 선언를 가진 당신의 XML파일을 버리지 마라. 그것들은 Spring내에서 재사용가능할것이다.

Error 와 Validation Messages

좀더 좋은 소식이 있다.

Spring은 동일한 형태로 Struts message번들을 인식한다.

Spring MVC내 존재하는 Message자원들을 재사용하기 위해서, 당신은 Spring MVC 설정파일내 messageSource가 다음처럼 설정한다.

 

<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">  <property name="basename">   <value>resources.ApplicationResources</value>  </property> </bean>

또한, 당신은 Controller구현물내 messageSource프라퍼티로써 당신의 Controller처럼 이것을 사용할 필요가 있다.

요구되는 변경사항은 없다.

Dispatcher Servlet

Spring MVC는 Request Processor/Action Servlet의 자신만의 버전을 가진다.

이것은 URL표시그룹으로 맵핑되는 DispatcherServlet이다.

Dispatcher Servlet의 개념을 이해하기 위해서, Controller를 Spring MVC내 설정하는 방법을 보자.

설정파일들

Struts사용자라면, 당신은 모든 forward, action mapping, form definition 그리고 플러그인 선언등을 가지는 적어도 하나의 struts-config.xml파일을 사용한다.

Spring MVC에서, 모든 웹 애플리케이션관련 컨트롤러 선언은 Spring Beans처럼 설정된다.

하나이상의 Dispatcher Controller는 웹자원을 위한 모든 요청을 적당한 Controller로 보낸다.

예를 들면, 만약 당신이 ".do"애플리케이션을 Spring MVC애플리케이션으로 다시 맵핑시키길 원한다면,

당신은 애플리케이션의 web.xml에 다음처럼 서블릿 맵핑을 등록하라.

(나는 당신이 .do 확장자를 사용하는것을 실질적으로 권하지 않는다. Struts만 사용하는 규칙처럼 ".do"를 남겨두라.)

 

<servlet>  <servlet-name>applicationDispatcher</servlet-name>  <servlet-class>   org.springframework.web.servlet.DispatcherServlet  </servlet-class>  <load-on-startup>1</load-on-startup> </servlet>         ... <servlet-mapping>  <servlet-name>applicationDispatcher</servlet-name>  <url-pattern>*.do</url-pattern> </servlet-mapping>

지금 당신은 Spring MVC Controller선언을 가진 Spring 설정파일(applicationDispatcher-servlet.xml)을 가진다.

"-servlet.xml"는 applicationDispatcher파일을 위한 접미사이다.

이것은 Spring MVC맵핑파일을 자동 리로드하는 DispatcherServlet을 가능하게 하는 Spring MVC규칙이다.

Spring MVC내에서 웹 action을 적당한 컨트롤러로 맵핑하는것은 매우 쉽다.

이것은 Spring애플리케이션의 일부처럼 같은 "wiring"형태로 수행된다.

다음의 예제는 URL expression /showCatalog.do를 Controller showCatalog로 포워드하는 방법을 보여준다.

 

<bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">  <property name="mappings">   <props>           <prop key="/showCatalog.do">showCatalog</prop>   </props>  </property> </bean>

Controller showCatalog는 Controller인터페이스를 구현하는 클래스에 의해 구현된 다른 빈처럼 설정될것이다.

이 예제에서, showCatalog는 URL요청을 카테고리로 명명된 ModelAndView컴포넌트로 포워드하는 간단한 포워딩 컨트롤러에 지나지 않는다.

 

<bean id="showCatalog" name="showCatalog" class="org.springframework.web.servlet.mvc.ParameterizableViewController">  <property name="viewName" value="catalog"/> </bean>

Struts에서 Spring MVC로의 이전 경로.

Struts애플리케이션을 Spring MVC로 이전하기 위해서는 3가지 접근법이 있다.

몇몇은 애플리케이션을 점차적으로 이전할것이다.

다른것들은 Struts프레임워크를 완벽하게 포기하고 완전히 다시 쓰는 작업을 수행할것이다.

접근법들은 아래에서 개요를 말하고, 이전의 완벽함 순서대로 정렬된다.

 

1. Spring은 Struts컴포넌트를 가능하게 한다.

천천히 이전하길 원하는 사람들을 위해, 첫번째이고 완벽하게 이전에 따른 무리가 없는것은.?

Spring Beans처럼 Struts Actions를 가능하게 하는것이다.

이것은 간단한 작업이고, Spring문서에 잘 설명되어 있다.

이것은 Struts코드에 대한 변경을 요구하지 않지만,

이것은 Spring Beans처럼 처리되기 위해 Struts Controller컴포넌트, Actions를 가능하게 한다.

이 처리로, Actions은 Spring Beans의 상태를 상속한다.

그러므로, Spring Controller처럼 많은 것을 보기 시작하라.

늦으면서 단계별로 현명한 이전은 이 처리로 가능하다.

각각의 Action은 애플리케이션 재작성과 현재 웹 연속물의 중단없이 Spring Controller에 의해 한번에 대체될수 있다.

 

2. Tiles를 사용하는 Spring Spring프레임워크에 의해 완전히 제공되는 다른 대체물은 순수한 "view" 프레임워크처럼 Tiles를 유지하는 동안 Spring MVC컴포넌트로 Struts Controller과 관련 컴포넌트(Actions, Form Beans, 등등)를 대체하는것이다.

Spring MVC는 Tiles에 대한 특정 대안을 가지지 않는다. 그래서 구조는 Tiles에 대한 것을 유지하기로 결정하고 Spring MVC를 통해 그 작업을 하도록 만든다.

이 접근법의 하나의 심각한 단점은 당신이 웹애플리케이션내 두개의 다양한 웹 프레임워크를 효과적으로 유지관리하기 위해 유지관리를 위한 많은 노력과 두가지 프레임워크를 위한 추가적인 학습이 필요하다는 것이다.

 

3. 완전한 이전 완전한 이전은 Struts프레임워크의 모든 컴포넌트를 Spring MVC로 교체하는것을 의미한다.

이 처리의 마지막에는 Struts특성의 컴포넌트는 애플리케이션에 남지않는다.