2. Building Model Components

2. Building Model Components

"If I had a world of my own, everything would be nonsense. Nothing would be what it is, because everything would be what it isn't. And contrary wise, what is, it wouldn't be. And what it wouldn't be, it would. You see?"

2.1 Overview

많은 요구사항 문서는 웹 애플리케이션 개발에 있어서 View에 포커싱을 두고 있다. 그러나 각 submit된 요청에 대해서 처리를 확실히 하고자 한다면 Model관점에서 명확하게 정의해야 한다. 일반적으로 모델 컴포넌트의 개발은 기능 요구사항의 JavaBeand의 생성에 초점을 둘 것이다. 특정 애플리케이션에 의해서 요청된 빈의 정확한 본질은 그러한 요구사항에 광범위하게 관련되어 있다. 그러나 일반적으로는 아래에서 이야기하는 몇가지 카테고리에 의해서 분류될 수 있다. "scope"의 개념에 대해서 간단히 리뷰할때, bean과 JSP의 관계에 대해서 우선적으로 살펴보는것이 유용할 것이다.

2.2 JavaBeans and Scope

웹 기반 애플리케이션에서 JavaBean은 서로다른 몇개의 "attribute"의 조합으로 구성된다. 각 컬렉션은 컬렉션의 생명주기에서 서로 다른 룰을 가지고 있다. 생명주기를 정의하는 룰과 가시성은 scope라고 부른다. JavaServer Page에서는 다음과 같은 용어로 스코프를 정의하고 있다.

• page - Bean은 단일 JSP에서만 보인다. 즉 현재 요청의 생명주기에서만 유용하다. (서비스 메소드의 지역변수에 해당한다.)
• request - 빈은 단일 JSP페이지에서 보인다. 어떠한 페이지에서든지 혹은 서블릿에서 이 페이지를 포함한 경우 혹은 이 페이지에서 포워드된 경우 보인다. (요청 attribute가 해당)
• session - 빈은 모든 JSP페이지와 사용자 세션 하에 있는 서블릿에서 보인다. 하나 혹은 이상의 요청에 대해서 모두 볼 수 있다. (Session attributes)
• application - 빈은 모든 JSP페이지와 웹애플리케이션 파트의 서블릿에서 볼 수 있다. (Servlet context attribute)

이것은 기억해야할 중요한 것이다.  JSP페이지와 서블릿에서 빈 컬렉션의 집합에 동일하게 공유되는 내용이다. 예를 들어 서블릿은 아래와 같이 빈은 요청된 attribute를 저장한다.

MyCart mycart = new MyCart(...);

request.setAttribute("cart", mycart);

이것은 포워딩된 JSP페이지에서 즉시 볼 수 있으며, 표준 액션 태그는 이렇게 해서 값에 접근할 수있다.

<jsp:useBean id="cart" scope="request"

class="com.mycompany.MyApp.MyCart"/>

2.3 ActionForm Beans

노트 : ActionForm빈은 대개 프로퍼티를 가지며, Model의 빈과 매칭된다. 폼빈은 컨트롤러 컴포넌트로 고려된 객체이다. 그러므로 Model과 View레이어 사이에서 데이터 전달을 담당한다.

Strtus 프레임워크는 일반적으로 ActionForm빈의 정의를 애플리케이션의 입력 폼을 위해서 만든다고 가정하고 있다. (이 클래스는 ActionForm클래스를 상속받아서 사용한다.) ActionForm 빈은 가끔 form beans라고 부른다. 이것은 정교하게 수집된 객체이며, 각 폼은 하나의 빈을 가지고 있다. 또한 몇몇 폼들을 지원해주기 위해서 조악하게 모인 것일 수 있다. 또한 전체 애플리케이션에 이용될 수도 있다.

만약 그러한 빈을 Struts configuration파일에 정의한다면 (see Writing Action Mappings) 보면 된다. Struts 컨트롤러 서블릿은 다음과 같은 서비스를 자동적으로 수행해준다. Action메소드를 호출하기전에 말이다.

• 적당한 클래스 빈 인스턴스를 체크한다. 적당한 키에 대해서 적당한 스코프 영역을 확인한다. (request나 session)
• 만약 인스턴스 빈을 찾지 못한다면, 새로운 것은 자동적으로 생성되고 적당한 스코프 영역에 추가된다. (request나 session)
• 매 request parameter를 위해서 빈의 속성 이름에 대응되는 이름으로 대응되며, setter메소드를 호출하여 이에 해당하는 값이 설정된다. 이것은 표준 JSP의 <jsp:setProperty>액션과 유사하며, 모든 프러퍼티를 위해서 *를 사용하는 내용과 동일하다.
• ActionForm 빈을 업데이트 하고 Action클래스의 execute메소드에 전달한다. 그리고 시스템 상태와 비즈니스 로직 빈에 맞도록 값을 지정할 수 있다.

Actions과 ActionForm빈의 코딩에 대해서 더 많은 내용을 알고자 한다면 Building Controller Components 을 확인하자.

"form"을 기술함으로 해서 단일 JSP 페이지에서는 대응되는 값이 필요없게 된다. 이것은 공통적으로 많은 애플리케이션에서 "form"을 가지고 있으며 많은 페이지로 확장된다. 생각해보면 한예로 위자드 스타일의 사용자 인터페이스는 공통적으로 새로운 애플리케이션을 인스톨할때 사용된다. 스터러츠는 필드의 모든 프로퍼티를 포함할 수 있도록 단일 ActionForm을 정의하라고 장려한다. 필드의 내용이 화면에 안보일 지라도 말이다. 이것과 같이 다양한 페이지에서 동일한 폼을 지정하면 서브밋을 동일한 Action클래스로 보낼 수 있다. 만약 다음과 같은 의견을 제시한다면 페이지 디자이너가 비즈리스 처리 로직의 변경 없이 다양한 페이지 사이에서 필드를 다시 정렬하고자 한다고 할때 유용할 것이다.

작은 애플리케이션에서는 단일 ActionForm이 입력폼의 모든 항목을 서할 수 있을 것이다. 다른 애플리케이션은 아마도 각 주요 서브 시스템마다 단일 액션폼을 이용해야 할수도 있다. 그래서 팀은 각 구별되는 입력 폼이나 워크플로우에서 액션폼을 분리하고자 할 수 있을 것이다. 얼마나 많은  혹은 얼마나 작은 액션 폼을 전체 시스템에 이용할지는 당신에게 달려있다. 프레임워크는 거기에 대해서 관여하지 않는다.

2.4 System State Beans

시스템의 실제적인 상태는 보통 하나 혹은 이상의 JavaBean클래스의 셋으로 표현된다. 프로퍼티는 현재 상태를 정의한다. 쇼핑카트 시스템의 예를 들면 각 쇼핑자들의 카트를 관리하여야 한다. 그리고 현재 쇼핑하고자 하는 사람이 구매하기로 선택한 아이템을 카트에 넣아야 한다. 별개로 시스템은 사용자의 프로파일 정보를 위해 다른 빈들을 포함하고 잇어야 하며 이것은 가능한 아이템의 카달로그나 현재 인벤토리 레벨에 따라 구분되어야 한다.

작은 규모의 시스템이나 상태정보를 위해서는 오랜기간 유지할 필요가 없을 것이다. 시스템 상태 빈의 세트가 가지고 있어야할 것은 특정한 몇가지 상세한 정보들에 대한 모든 지식을 가지고 잇어야 한다. 혹은 몇가지 케이스에서 시스템 상태빈은 외부 데이터베이스에서 유지해야할 값들에 대한 정보(고객 테이블에서 가져온 데이터를 가진 CustomerBean과 같은것)나 서버의 메모리에 있어야할 내용을 생성하거나 제거하는 것들이 될 것이다. 엔터프라이즈 자바 빈의 엔티티는 또한 거대한 스케일의 애플리케이션에서 이러한 목적을 달성하기 위해서 존재한다.

2.5 Business Logic Beans

애플리케이션에서 기능로직의 캡슐화를 해당 목적을 위해 디자인된 자바빈즈의 메소드 호출에 대해 수행할 수 있다. 이러한 메소드는 시스템의 상태빈의 이용을 위해 동일한 클래스의 부분으로 이용하거나, 로직 수행을 결정하기위한 분리된 클래스일 수 있다. 나중에 나올 케이스에서 시스템 상태 빈을 메소드 아규먼트로 패스하길 원할 것이다.

최대한 코드 재 사용을 위해서 비즈니스로직은 웹 애플리케이션에서 수행될때 그들에 대해서 잘 알지 못다더라도 수행가능하도록 디자인되고 구현되어야 한다. 만약 javax.servlet.* 클래스를 빈에서 호출하고자 할경우 임포트를 해야한다. 그러나 이러한 것을 웹 애플리케이션 환경의 비즈니스 로직을 정의해서 사용할 수 있을 것이다. Action클래스가 HTTP리퀘스트로 부터 요청되는 정보의 변화를 setter을 호출함으로 해서 수행할 것이고, 그런다음 execute메소드를 호출할 수 있도록 만들수 있다. 그러한 비즈니스 로직 클래스는 초기화 생성자를 이용하여 웹 애플리케이션에 적용하는 대신 환경에서 재 사용할 수 있을 것이다.

애플리케이션의 scope와 복잡도에 의존되어 비즈니스 로직 빈은 일반 자바 빈과 시스템 상태 빈에 전달된 아규먼트와 상호 통신 하거나, 혹은 일반 자바 빈이 JDBC콜을 이용하여 데이터베이스에 접근하는 작업을 수행할 것이다. 좀더 큰 애플리케이션을 위해서 이러한 빈은 stateful 혹은 stateless로 엔터프라이즈 자바 빈즈에 이용될 것이다.

애플리케이션에서 데이터베이슬르 이용하기 위해서는 Accessing a Database HowTo을 참조하라.

더 많은 비즈니스 로직과 프레임워크 데이터에 엑세스 하기 위해서 key technologies primer를 참조하라.

2.5.1 DynaBeans

DynaBeans는 자바 빈의 확장으로 연결되며 Map의 유연함을 이용한다. 단순한 자바 빈은 새로운 클래스와 코딩 필드 그리고 각 프로퍼티를 위한 2개의 메소드를 필요로 한다. DynaBean의 프로퍼티는 XML디스크립터로 설정할 수 있다. DynaBean의 가상 프러퍼티는 표준 자바 메소드에서 호출 할 수 없다. 그러나 리플렉션과 인스트로펙션에 의한 컴포넌트와 작업할 수 있도록 되어 있다.

애플리케이션에서 DynaBean을 HTML 폼에 이용하고 싶다면 정형화된 JavaBean의 서브 클래스를 생성하는 것을 피하고 몇가지 단순한 프로퍼티를 저장하는 것으로 만드는 것을 피해야 한다.

DyanBean에 대해서 더 많은 정보를 원한다면

• The Commons BeanUtils Package Description and Javadocs.
• Struts FormDef

2.6 Commons Chain

복잡한 프로세스 플로우의 실행을 조직적으로 처리하기 위한 일반적인 기능은 "Chain of Responsibility"패턴으로 "Gang of Four" 디자인 패턴 북에 설명되어 있다. GoF는 Chain of Responsibility 패턴에 대해서 "Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it."로 묘하산다.

CoR 패턴은 소프트웨어 컴포넌트를 loosely coupled하게 유지한다. 컴포넌트는 Chain of Responsibility로 부른다. 이것은 어떤 객체가 어떻게 그들의 객체를 구현했는지에 대해서 알지 못한다. 가장 중요한것은 어떻게 Chain의 호출을 호출자에게 호출하는지 알릴 필요없이 Chain을 조정가능하다는 것이다. Version 1.3에서처럼 기본 Request Processor은 프레임워크의 "kernel"의 역학이 Chain of Responsibility가 된다.

이러한 Chain을 구현하는것은 Request Processor가 Chain of Responsibility 컴포넌트를 (Jakarta Commons에 정의되어 있음)을 이용하는 것으로 CoR패턴을 구현하고 있는 컴포넌트를 컨텍스트의 구현이나 커맨드 객체의 구현을 요청된 서비스의 체인에 의해서 이용되는 것을 말한다.

Chain of Responsibility에 대해서 더 많은 정보를 원한다면

• Jakarta Commons Chain of Responsibility
• A look at Commons Chain
• Better Code with Struts 1.3

Struts 1.3에서 공통적인 Chain은 프레임워크의 기본 Request Processor을 구현하는데 있다.