Intra-Business 티어 패턴 - Value List Handler
2007/05/25 01:05
1. 고려해야 할 사항
2. 해결방안 - Value List Handler 패턴의 구조

3. 해결방안 - Value List Handler 패턴의 시퀀스

4. 구현전략
5. 예제 및 코드

6. 결과
7. 관련 패턴
- 클라이언트 어플리케이션은 효율적인 쿼리 기반의 기능을 필요로 할 때, finder 메소드는 시스템의 오버헤드를 많이 증가시키기 때문에 사용을 피하는 것이 좋음.
- 비즈니스 티어는 캐싱 메커니즘을 지원하고 있기 때문에 클라이언트는 많은 양의 데이터을 한번에 받아서 처리할 필요는 없음.
- 쿼리 수행 결과인 검색 데이터 양은 대용량이며 보통 주로 읽기 전용.
- 이런 대용량 데이터를 브라우징하거나 캐싱하고자 할때 EJB 콤포넌트가 제공하는 finder 메소드를 사용하는 것은 적합하지 않음. EJB 콤포넌트가 제공하는 finder 메소드는 동시에 접근해서 데이터를 읽어서 수정할 수 있는 작은 사이즈의 데이터를 쿼리하고자 할때 적함.
2. 해결방안 - Value List Handler 패턴의 구조

3. 해결방안 - Value List Handler 패턴의 시퀀스

4. 구현전략
- Stateful Session Bean Handler
Value List Handler는 보통 Stateful Session Bean으로 구현되거나, Stateful Session Bean에 의해 억세스됨. - POJO Handler
어플리케이션이 EJB 콤포넌트를 사용하지 않을 경우, Value List Handler는 POJO로 구현될 수 있음. 이때, POJO는 Business Delegate에 의해 직접 억세스 됨. - Value List from DAO
DAO는 JDBC ResultSet, JDBC Rowset, 또는 컬렉션과 같은 다양한 포맷으로 결과를 리턴할 수 있음.
5. 예제 및 코드

6. 결과
- 장점
finder 메소드를 사용될 경우 많은 오브젝트 생성으로 인한 오버헤드를 피할 수 없음.
캐시를 구현함으로써 쿼리 결과를 재사용.
많은 양의 쿼리 결과를 한번에 클라이언트에게 전달하는 것이 아니라 클라이언트가 요청할때 필요로 하는 데이터만 전달함으로써 네트워크 오버헤드를 줄일 수 있음. - 단점
캐싱은 메모리를 많이 소모하고 수행속도를 저하 시킴. 따라서 디자이너는 수행속도를 개선하기 위해 캐싱 메커니즘을 사용하기 전에, 클라이언트의 요청을 캐싱되어 있는 데이터를 이용한 처리 횟수가 테이터 스토어에 억세스하여 처리하는 횟수보다 많은지 분석해야 함.
Value List의 값을 변경시킬 경우 수행속도가 떨어지게 됨. Value List의 값을 변경시킬 경우 데이터 스토어에 있는 데이터와 일치시키기 위해 데이터 스토어에 억세스해야 함.
7. 관련 패턴
- Iterator
