Struts 의 개요
1.Struts란
1. Jakarta 서브 프로젝트로 개발됐습니다.
2. Web 어플리케이션을 위한”가벼운 중량” 체제입니다.
3. MVC 모델2의 Contoroller과 View의 부분을 몸체로써 제공하고 있습니다.
2. Struts의 목적
Java Servlet나 JavaServer Pages (JSP)의 기술을 이용하고 Web 어플리케이션을 구축한 데에 유용한, 오픈 소스 체제를 제공하는 것입니다.
3. Struts의 주기능
1. 리퀘스트를, 어플리케이션 개발자가 제공한 적절한 Action 클래스에 할당한 컨트롤러 Servlet의 제공.
2. JSP 커스텀·태그·라이브러리 및,대화적 폼 베이스 어플리케이션을 구축한 때에 개발자를 돕는 컨트롤러 Servlet에 있어서 통합 지원.
3. XML의 parse,Java 리플렉션 API를 베이스를 둔 JavaBeans프로퍼티의 자동 설정, 메시지나 프롬프트의 국제화,등을 지원한 유틸리티 클래스의 제공.
4. Struts의 구성요소
1. 액션,서블릿
MVC 모델2의 컨트롤러로써 작동하는,모든 HTTP 리퀘스트의 입구가 되는
컴포넌트입니다.
2. 액션·매핑
URL과 Struts에 있어서「액션」과의 매핑 정보를 지원하는 컴포넌트입니다.
액션·배치·파일으로부터 자동적으로 생성됩니다.
3. 액션·폼 Bean
클라이언트로부터 송신된 HTTP 리퀘스트의 폼·데이터를 격납하는 컴포넌트입니다.
4. 액션·클래스
비즈니스 로직을 호출하고,쓰기 위한 컴포넌트입니다.
5. JSP
처리 결과로 된 HTTP 응답(HTML 파일)을 생성한 컴포넌트입니다.
※ Struts에 있어서「액션」이란 ...
비즈니스·로직을 실제로 처리하는 액션·클래스와 클라이언트로부터 송신된 데이터를 격납한 액션·폼 Bean과 액션·클래스 실행후의 이동 정보를 나타내는 포워드 정의를 정리한 것입니다 (포워드 정의:어디로 움직일 것인가, 어느 페이지로 갈것인가의 정의)
Struts 구성 요소
5.개발자가 작성한 것
1. 액션·배치·파일
Struts에 있어서 액션의 정의를 행하는 struts-config.xml이라고 하는 XML파일입니다.
이 파일으로부터 시동시에 액션·매핑 클래스가 자동적으로 생성됩니다. 화면 이동등의 동작을 정의합니다.
例 <action path="/logon“ type="jp.co.argo21.ess.struts.example.action.LogonAction“ name="logonForm" scope="request“ validate="true“ input="/logon.jsp"> <forward name="failure" path="/failure.jsp"/> <forward name="welcome" path="/orderList.do"/> </action> |
액션·배치·파일으로는 ,액션·폼 Bean이나 JSP의 논리명을 붙이는 일을 할 수가 있습니다.(액션·폼 Bean은 필수) 또,액션·클래스 실행후의 이동하는 곳도 코드 안에서는 설정하지 않고,이 파일의 포워드 정의를 지정합니다.
(예로는,결과가 ”welcome”의 경우,”orderList”액션에 이동한다)
이렇게 함으로써 각 컴포넌트의 유니트화가 촉진되어 집니다.
한편으로,각 컴포넌트가 약하게 결합하고 있기 때문에 ,컴파일러에 의한 체크가 각각 다르고,
실행시 에러가 발생하기 쉽다라는 문제가 있습니다.
툴에 의한 액션·배치·파일의 작성 지원이나 움직이는 곳을 메소드로 관리하는등의 수단을 검토할 필요가 있습니다.
2. 액션·폼 Bean
클라이언트로부터 송신된 HTTP 리퀘스트의 폼·데이터를 격납된 컴포넌트 입니다.필요에 따라서 액션 서블릿에 따라 생성됩니다. 폼·데이터의 Validation을 실행하기 위한 처리가 정의되고 있고,액션·배치·파일로 Validation을 실행하도록 정의되고 있는 경우,그 처리가 액션· 서블릿에 의해서 실행해집니다.
액션·폼 Bean은 반드시1 화면에 1개 필요해지는 것은 아니고,각 화면에서 공유한 것을 할 수 있습니다.
3. 액션·클래스
비즈니스·로직을 호출하고,기술하기 위한 컴포넌트입니다.액션· 서블릿으로부터 호출됩니다.
필요에 따라서 액션·폼 Bean으로부터 폼·데이터를 얻어내고,비즈니스·로직을 실행합니다.
비즈니스·로직의 처리 결과를 화면에 표시한 경우는 ,액션·폼 Bean에 ,다른 액션이라고 공유하거나 한 경우는 ,상태를 보존한 스테이트 Bean을 별도 작성하고,적당한 문맥에 격납한 것이 필요해집니다. 비즈니스·로직의 실행 후,액션·매핑에 정의된 포워드 정의의 「논리명」을 사용하고 화면 천이의 제어를 행합니다.
이것에 의해서,어디로 움직일지의 정보를 액션·클래스가 알고 있을 필요가 없어지고,화면
이동이 변경이 된 경우에는 쉽게 보수 할 수가 있습니다.
DB 조작등의 비즈니스·로직은 ,별도 Bean로 처리를 행하도록 하여, Validation이나 콘트롤러로서의 기능으로 한정하도록 설계해야 합니다.
4. JSP
처리 결과로 된 HTTP 응답(HTML 파일)을 생성합니다. Struts 태그·라이브러리를 이용하고,표시를 위한 데이터를 참조하고,클라이언트에게 송신한 HTML 파일을 생성합니다.
스크립트 렛(<%~%>의 속에 java의 코드를 쓰는 것)은 가능한한 사용하지 않고,커스텀·태그로 코딩하게 해야 합니다.
6.유의한 점과 힌트
1. 데이터의 공유에 관하여
데이터를 여러의 비즈니스·로직으로 공유하거나 ,여러 화면에서 표시하거나 한 경우는 ,일반적으로 은 ServletContext나 Session이라고 한 적당한 스코프의 문맥에 격납합니다. Struts로는 ,이것 이외에도 데이터를 액션·폼 Bean의 프로퍼티에 보존한 것으로 데이터의 공유가 가능합니다.
이 방법의 이익은 ,
· 액션·폼 Bean의 인스턴스는 ,액션·클래스의 방법 perform의 인수로서 건네받기 때문에 특별한 선언 없이도 사용할 수 있다
· 액션·배치·파일의 기술만으로 ,다른 액션 클래스로부터 사용 할 수 있게 됩니다.
· 표시뿐만 아니라 입력 폼으로서 이용됩니다.
다만 ,주의해야 할 점으로서 1 액션에 대해 하나의 액션·폼 Bean밖에 이용할 수가 없다고 합니다.
이 때문에,액션·폼 Bean에 데이터를 전부 밀어 넣고 클래스를 비대화시키고 마는 위험성이 있습니다.또,데이터의 스코프가 액션·폼 Bean과 똑같이 되고 버리기 때문에 ,쓸데없은 데이터를 지원하고 유지될 가능성이 있습니다.
데이터를 어떻게 공유하는가의 지표로서는, 「어플리케이션·데이터는 ,라이프· 사이클에 따르는 적당한 스코프의 문맥에 ,스테이트 Bean으로서 보존한다.또,액션·폼 Bean은 ,액션에 대한 입력에만 사용한다.다른 액션과의 사이에서 공유하고 있는 액션·폼 Bean을 ,어플리케이션·데이터의 주고 받는것을 위해서 사용하면 안된다.」고 말할 수 있습니다.
2. 화면분할과 액션
Struts로 WEB 어플리케이션을 작성하기 위해,특히 신경을 쓰는 화면분할을 행한 필요는 없다고 생각합니다만,1 액션으로 사용할 수 있는 액션·폼 Bean은 하나이므로,이 점을 화면 설계로 유의하지 않으면 안될 것입니다.
또,한개의 액션으로 한개의 화면이라고 생각하면 ,한개의 화면에 대해 최저2 내지3의 컴포넌트가 필요해집니다(액션·클래스,JSP와 액션·폼 Bean).이 때문에,화면의 이동 이외에 어느 화면(액션)으로 어느 컴포넌트를 사용하고 있을까,이동시에 어떤 액션·포워드 정의를 사용하고 있는지를 설계 단계에서 명확하게 해 두는 것이 필요하게 됩니다.
3. 명명 규칙
Struts로는 ,대부분(거의)의 컴포넌트를 논리명으로 사용할 수 있게 되어 있습니다.그 때문에,실제의 클래스(class)명·JSP 이름은 자유롭게 변경할 수 있습니다만 ,개발 효율의 관점에서 미리 명명 규칙을 정하고 두는 것이 중요합니다.개발 환경 규약에 규정한 것이 됩니다만 ,샘플으로는 이하의 명명 규칙을 채용했습니다.
· 액션·폼 Bean 이름=「액션 이름」+Form
· 액션 클래스(class)명=「액션 이름」+Action
· JSP 파일(file)명=「액션 이름」.jsp
또,액션 클래스의 결과인 포워드 정의는 코드에 들어가기 때문에 보수의 면에서 변경하지 않는다 것이 바람직합니다.그 때문에, 포워드 정의에 대해서도 명명 규칙을 정하고 두는 쪽이 좋을 것입니다. 또,포워드 정의는 화면 이동에 밀접하게 관계되고 있기 때문에,할 수 있으면 화면 설계의 단계에서 결정할 수 있었던 쪽이 좋을 것입니다.
4. Validation의 실장 장소에 관하여
Struts의 Validation은 액션·폼 Bean의 validate 방법과 액션·클래스의 perform 방법의 2 부분으로의 실행될 것이라고 생각됩니다. 액션·폼 Bean이 화면의 입력 폼과 결부되고 있기 때문에 ,입력 데이터의 null 체크·항수 체크나 범위 체크등,이 단체(하나)로 체크가 행할 수 있는 것에 관해서는,validate 방법으로 입력 체크를 행하고, 그 밖의 예를 들면 데이터베이스에 해당한 데이터가 격납되고 있는지 아닌지의 체크등은 ,perform 방법으로 행하도록 한 것이 좋을 것입니다.
5. 유틸리티·클래스의 활용 Struts에는 ,커스텀·태그·라이브러리를 시작하고,
「Digester」이라고 한 유틸리티·클래스(패키지)가 존재합니다. JSP를 기술한 때에 ,커스텀·태그는 강력한 툴으로 되기 때문에 이것들을 효과적에 활용한 것이 필요하다고 생각됩니다.
'프레임워크 > Struts2' 카테고리의 다른 글
Struts2 기본형태 (0) | 2016.01.11 |
---|---|
스트럿츠의 기본형태 (0) | 2015.12.22 |
Struts2 에서 validator 사용하기. (0) | 2015.11.20 |