[펌] 회사 내에서 정리해 본 내용

1. ActinoForm 사용전략의 종류
① 도메인 객체 Bean과 1:1 매치되는 ActionForm 생성
② 통합적으로 사용가능한 하나의 ActinoForm 생성
③ 도메인 객체 Bean을 자신의 property로 가지는 ActionForm 생성
④ 내부에 Map 객체를 가지는 ActionForm 생성
⑤ 별도의 클래스 파일 없이 struts-config.xml에서 정의해서 사용하는 DynaActionForm 생성

2. 각각의 특징과 장단점
①번의 장점
-. 도메인 객체 Bean과 1:1 매치되는 방식이므로 데이터 이동이 명확하며 전체 애플리케이션 구조 이해가 수월하다.
-. BeanUtils.copyProperties 메써드 사용으로 Action 단에서의 처리로직이 거의 필요없다.
①번의 단점
-. 도메인 객체 Bean의 개수에 따라 ActionForm 클래스를 만들어줘야 하므로 큰 애플리케이션일수록 작업량이 많아지게 된다.
-. 도메인 객체 Bean의 설계에 종속적이므로 도메인 객체의 변경에 따라 계속적인 유지보수가 발생하게 된다.(매치되는 도메인 객체 Bean과 property 이름이 같아야 하므로)

②번의 장점
-. 하나의 ActionForm 클래스로 여러가지 Action에서 사용하게 되므로 재사용성이 높으며, 유지보수할 클래스 개수가 현저하게 줄어든다.
②번의 단점
-. 하나의 ActionForm에서 여러 도메인 객체 Bean property와 매치시켜야 하므로 도메인 객체 Bean 설계시 비슷한 property 이름을 통일시켜주는 작업(예를 들어 각 도메인 객체 Bean의 pk 속성의 이름은 id로 통일한다는 등)을 해주거나(Layer간 의존도가 높아짐), 해당 Action에서 불필요한 데이터까지도 담게 됨으로써 통신시 부하가 상대적으로 높아질 것이다.

③번의 장점
-. 도메인 Bean을 ActionForm 내에서 직접 property로 가지고 있게 됨으로써 데이터 copy와 같은 단계가 필요없으며, 도메인 객체 Bean 내부의 변경이 ActionForm 자체에 영향을 주지 않음으로써 Layer간 의존도를 낮출 수 있다.
-. Bean에서의 프라퍼티를 일일이 ActionForm 에서 매치되게 구현해주지 않아도 됨으로써 클래스 구조를 간단하게 만들며 유지보수를 쉽게 해준다.
③번의 단점
-. 내부의 도메인 객체 Bean에서 String, Boolean 이 아닌 다른 타입(숫자형 타입 Long, Integer 혹은 날짜형 타입 Date, Timestamp 등)을 가지고 있게 될 경우, 사용자 입력 오류 등의 경우에, ClassCastException이 발생할 가능성이 높으며, 이에 대한 에러 처리에 어려움을 가진다.
-. ActionForm 의 내부 propery인 Bean이 가지고 있는 property에 대한 Validation 체크를 위한 xDoclet 사용이 안됨으로 인해 개발자 공통의 xml 생성 및 관리에 불편함을 초래한다.

④번의 장점
-. ③번의 경우와 비슷하게 도메인 객체 Bean의 property의 변화와 관계없이 ActionForm 내부의 Map property에 set/getValue() 해주면 되기 때문에 단순한 형태의 ActionForm 생성이 가능하며 유지보수 대상 클래스가 줄어든다.
-. org.apache.struts.scaffold.BaseMapForm 을 상속받기만 하면 Map ActionForm 구현은 간단하게 끝난다.
④번의 단점
-. 역시 ③번과 마찬가지로 Validation 생성을 위한 xDoclet 사용이 불가능하며, 명확한 property가 명시되어 있지 않음으로 인해 클래스 전체 구조가 이해하기 힘들게 된다.(특히 유집보수를 다른 사람이 하게 될 경우)

⑤번의 장점
-. 각각의 클래스로 생성되어야 할 ActionForm 들을 struts-config.xml에서 태그만 정의해주면 되기 때문에 사용이 간편하며, ActionForm 관리가 용이해진다.
-. ActionForm 클래스를 하나도 사용하지 않아도 됨으로 인해 ActionForm 클래스 유지보수와 관련한 비용이 절감된다.
⑤번의 단점
-. 역시 Validation 생성을 위한 xDoclet 사용이 안되며, struts-config.xml 관리가 어려워진다.(config 파일의 거대화 혹은 merge 파일로 빼냈을 경우 관리의 복잡성)

3. 각각의 특징에서 본 우리의 ActionForm 사용전략
-. 일단은 case by case 의 입장을 견지한다.(각각의 사용전략은 그에 맞는 경우에 따라 최고의 효과를 가질 수 있으므로, 선험적인 제외는 올바르지 않다.)
-. 기본적으로는 도메인 객체 Bean과 1:1 매치관계를 가지는 ActionForm 을 작성한다.(어플리케이션의 구조가 직관적이며 Action단의 불필요한 로직발생을 최소화)
-. write, update 등과 상관없이 List 화면만 보여줄 경우 공통된 타입(List)으로 데이터를 받아오기 때문에 공통적인 하나의 ActionForm 작성으로 대체하는 것이 효율성 및 유지보수의 편리함을 극대화할 수 있다.
-. 위의 ListActionForm의 경우 검색조건이 있다면, 검색조건은 Map으로 관리하는 것이 편리하다.(검색조건은 화면에 따라 다를 수 있으며, 도메인 객체 Bean과 매치되는 property 속성이 아니므로 해당 검색 param을 key로, 넘겨진 값을 value로 가지는 Map으로 관리하는 것이 유리하다.)