가 제대로 이미 서비스 계층에 깨끗한 API있을 것입니다. 바라건대 Struts2 애플리케이션은 이미 Spring DI를 사용하고 있기를 바랍니다. Struts2 객체를 재사용 할 수있었습니다. 그러나 웹 레이어는 상대적으로 얇기 때문에 struts2 작업의 흔적을 제거하여 이상한 유물을 남기지 않고 개발을 단순화하는 것이 가장 좋습니다.
struts 사용자가 담당하는 네 가지 주요 부분이 있습니다.
- 뷰 계층의 액션 클래스
- Struts2 특정 태그
- 검증
- 인터셉터
이미 상당히 얇아 야 언급 된 액션 클래스, 그것은 주요 목적은 마샬링하는 것입니다 보기에가는 도중의 물건. (매개 변수를 정렬하려면 양식 매개 변수를 설정하고 유효성을 검사해야합니다.) 객체가 서비스 계층에서 획득되면, 대부분의 로직을 잘라내어 Spring Controllers에 붙여 넣을 수 있어야합니다. 서비스 계층에 있어야하는 논리를 찾으면이를 밀어 올려야합니다.
뷰 레이어의 태그에 대해서는 잘 모르겠습니다. 가능한 경우 스트럿츠 특정 태그를 jstl 태그로 대체하는 것이 가장 좋습니다. Struts2에는 거대한 태그 세트가 없으므로 태그 사이에 거의 일대일 매핑이 있어야하지만 매핑이 무엇인지 (그리고 어떤 lib가 가장 적합한 지) 파악해야합니다.
유효성 검사 - 스프링 MVC가 유효성 검사를 수행하는 방법을 모르겠습니다.
인터셉터는 크로스 커팅 문제를 해결하기 위해 스프링 인터셉터가 어떻게 작동하는지 모르겠다. Spring은 아마도 AOP와 함께 커스텀 인터셉터의 문제를 해결할 수있다.
모두 웹 계층은 매우 침략해서는 안되며 ... 나는 무엇을 얻을지 확신하지 못합니다. 현재 S2 애플리케이션이 Spring DI를 사용하지 않는다면 AOP와 함께 추가하기가 아주 쉽고 Spring 생성을위한 작업 생성을 위임 할 수 있다는 점에 유의하십시오. 따라서 그러한 전환에서 나는 거의 수익을 기대하지 않을 것입니다.대안으로, Spring MVC를 사용하여 필요한 것을 만들기 시작하고 struts2 액션을 웹 서비스 (JSON은 매우 쉽다)로 전환하는 것이 더 쉽다. 그런 다음 스프링 MVC에서 구현할 시간이있을 때 조각을 현명하게 해체하십시오. 변환이란 두 시스템을 이해하고 매핑하는 것을 의미합니다. 이것은 지저분하고 오류가 발생하기 쉽습니다 ... 이것은 동일한 최종 결과 (struts2 프레임 워크 제거)를 가지지 만 생산성도 고려할 수 있습니다.
질문보기 ** ** [Struts2에서 Spring MVC로 마이그레이션] (http://stackoverflow.com/questions/2883459/migrating-from-struts2-to-spring-mvc) ** 및 ** [Struts2를 봄 mvc] (http://stackoverflow.com/questions/6421536/replacing-struts2-with-spring-mvc) ** – lschin