1. 서블릿 의존성
스트럿츠1에서의 Action은 Action이 호출될때 HttpServletRequest와 HttpServletResponse 오브젝트들이 execute 메소드를 통해서 전달되기 때문에 서블릿 API에 대해 의존성을 지니고 있었습니다. 그러나 스트럿츠2의 경우에는 Action클래스들이 단순한 POJO형태로 개발되기 때문에 컨테이너에 의존성이 없습니다. 스트럿츠2에서는 서블릿 컨텍스트가 단순한 Maps로 표현되기 때문에 격리된 환경하에서 Action에 대한 테스트가 가능합니다. 필요하다면 스트럿츠2의 Action은 원 request, response에 접근할 수 있습니다. 그러나 다른 아키텍쳐적인 요소들이 HttpServletRequest나 HttpServletResponse에 대한 직접적인 접근에 대한 필요를 감소시켜주었습니다.
2. Action 클래스들
인터페이스 기반이 아닌 추상클래스 기반으로 개발된 스트럿츠1의 디자인 관련 이슈들은 스트럿츠2에서 해결이 되었습니다. 스트럿츠1의 Action 클래스들은 프레임웍에 의존적인 기반 추상클래스를 상속받도록 되어 있었지만 스트럿츠2의 Action클래스들은 옵셔널하고 커스텀한 서비스를 적용하기 위해 인터페이스를 구현할 수도 있고 아예 하지 않을 수도 있습니다. 스트럿츠2의 경우 Action 클래스들은 단순 POJO들로 개발되기 때문에 컨테이너에 대한 종속관계가 없습니다. 스트럿츠2는 ActionSupport 클래스를 제공하여 공통적으로 사용되는 인터페이스들을 개발할 수 있도록 지원합니다.
그럼에도 불구하고 Action 클래스가 어떤 인터페이스를 구현하도록 요구되지는 않습니다. 어떤 POJO 오브젝트라도 execute 메소드만 존재한다면 스트럿츠2에서 Action 오브젝트로 사용이 가능합니다.
3. 검증(Validation)
스트럿츠1과 스트럿츠2는 둘다 validate 메소드를 통한 메뉴얼한 검증을 지원합니다. 스트럿츠1은 ActionForm내에 validate메소드를 통해 지원하거나 또는 Commons Validator에 대한 확장을 통해서 검증을 지원합니다.
그러나 스트럿츠2에서는 validate 메소드를 통한 메뉴얼한 검증방식과 XWork Validation 프레임웍을 통한 검증을 지원합니다. XWork Validation 프레임웍은 validation 컨텍스트와 프러퍼티의 타입을 위해 정의된 validation설정을 사용하여 validation chaining을 서브 프러퍼티까지 지원합니다.
4. 쓰레딩 모델
스트럿츠1에서 Action들은 반드시 thread-safe이거나 synchronized되어야 했었습니다. 그래서 Action들은 싱글톤이고 thread-safe했으며 해당 Action에 대한 모든 요청을 처리하기 위해 하나의 인스턴스만이 존재했습니다. 싱글톤 전략은 스트럿츠1의 Action에서 처리될 수 있는 일에 대해서 제한을 가져왔으며 추가적이고 조심스러운 개발을 요구했습니다.
그러나 스트럿츠2에서는 Action의 인스턴스들이 각 요청마다 생성됩니다. 따라서 더이상 thread-safe에 대한 이슈가 없습니다.(실제로 서블릿 컨테이너는 하나의 요청에 대해서 한번 사용하고 제거하는 오브젝트들을 많이 생성해냅니다. 그리고 이러한 추가적으로 생성되는 오브젝트들이 퍼포먼스와 가비지 컬렉션에 문제가 되지는 않습니다.)
5. 테스트의 용이함.(Testability)
스트럿츠1 기반의 어플리케이션은 테스트가 복잡했었습니다. 스트럿츠1의 Action을 테스트함에 있어서 가장 큰 장애는 execute 메소드가 서블릿 API에 노출되어 있다는 것입니다. 써드파티 모듈에 의한 확장, Struts TestCase 등이 스트럿츠1을 위한 mock 오브젝트를 제공하고 있습니다. 하지만 스트럿츠2의 Action은 Action을 인스턴스화하고 프러퍼티를 셋팅하고 메소드를 호출함으로써 테스트가 가능합니다. Dependency Injection가 지원되어 테스트 과정을 보다 단순화 할 수 있습니다. 스트럿츠2의 Action은 단순한 POJO들이며 프레임웍에 독립적이므로 스트럿츠2에서의 테스트환경은 아주 쉽습니다.
6. 입력값 수집 [출처] Struts1 VS Struts2|작성자 슬레이어
스트럿츠1은 사용자의 입력값을 받기 위해 ActionForm 오브젝트를 사용합니다. 그리고 모든 ActionForm들은 프레임웍에 의존적인 기반 클래스를 extend 하도록 되어 있습니다. JavaBean이 ActionForm으로 사용될 수 없기 때문에 개발자들은 입력값을 받기 위해 과다한 클래스들을 생성해야 합니다.
그러나 스트럿츠2는 Action클래스의 프러퍼티들(프레임웍에 독립적인 입력 프러퍼티로서)을 사용함으로써 추가적인 입력값 처리 관련 오브젝트들의 필요성을 제거했고 그리하여 과다하게 클래스가 생성되는것을 방지합니다. 추가적으로 스트럿츠2에서 Action클래스의 프러퍼티들은 웹페이지 상에서 태그라이브러리로 접근이 됩니다. 스트럿츠2는 POJO 폼오브젝트와 POJO Action을 지원할 뿐만 아니라 ActionForm형태의 사용도 지원합니다. 비즈니스 오브젝트나 도메인 오브젝트와 같은 타입들 역시 입력/출력값 관련 오브젝트로 사용이 가능합니다.
7. 표현식(Expression Language)
스트럿츠1은 JSTL과 통합되기 때문이 보통 JSTL을 EL로 사용합니다. 스트럿츠1은 기본적인 수준의 오브젝트내의 값에 대한 처리/순회를 지원하지만 상대적으로 컬렉션과 인덱스가 지정된 프러퍼티에 대한 지원이 약합니다. 스트럿츠2 또한 JSTL을 사용합니다만 보다 강력하고 유연한 Expression Langugae인 OGNL(Object Graph Notation Language)을 지원합니다.
8. 값을 뷰에 연결하기
뷰의 관점에서 보면 스트럿츠1은 오브젝트(Model에서 처리된 결과값을 담은)을 페이지 컨텍스트에 바인딩하기 위해 표준적인 JSP 메커니즘을 사용합니다.
하지만 스트럿츠2는 "Value Stack" 이란 기술을 사용하므로 View와 View가 렌더링할 오브젝트를 연결해놓지 않고도 태그라이브러리를 사용하여 값에 접근할 수 있습니다. Value Stack를 사용하여 값을 프로퍼티명을 사용하지만 그 타입이 다를 수도 있는 항목들을 가진 View들의 경우 해당 View를 재사용할 수 있습니다.
9. 형변환
보통 스트럿츠1에 있어 ActionForm의 프러퍼티값들은 모두 String형입니다. 스트럿츠1은 형변환시에 Commons-Beanutils를 사용합니다. 이런 타입컨버터들은 클래스당 하나씩 할당되고 인스턴트당 하나씩으로 설정할 수 없습니다.
하지만 스트럿츠2는 형변환에 OGNL을 사용합니다. OGNL의 구조는 기본적이고 공통적인 오브젝트의 타입과 프리미티브 타입에 대한 컨버터를 포함하고 있습니다.
10. Action의 실행에 대한 제어
스트럿츠1은 각 모듈당 별개의 RequestProcessors(라이프사이클)을 지원하지만 동일한 모듈내의 모든 Action들은 동일한 라이프사이클을 공유해야하만 합니다. 그러나 스트럿츠2는 Interceptor Stack을 사용하여 Action당 다른 라이프사이클을 가질 수 있도록 지원하고 있습니다. 필요하다면 커스텀 스택도 생성/사용할 수 있습니다.
댓글 없음:
댓글 쓰기