프리젠테이션(Presentation) 티어 안티 패턴 - Ad Lib TagLibs

2007/05/27 19:24
1. 문제점
Ad Lib TagLibs 안티 패턴은 태그 라이브러리에 비즈니스 로직 또는 컨트롤러 로직을 정의함으로써 발생하는 문제점들에 대해 기술하고 있는 패턴으로, 이 패턴이 지적하고 있는 문제점을 살펴보면 다음과 같음.

Service to Worler 패턴 기반의 아키텍쳐를 사용할 경우, JSP 페이지는 반드시 뷰 컴포넌트로 사용되어야 함. 즉, JSP 페이지는 모델 또는 컨트롤러의 기능을 포함하지 말아야 함. 커스텀 태크는 뷰의 조력자의 역할을 수행향 함.
이런 관계에서, JSP 페이지는 모델 또는 컨트롤러의 기능을 포함하지 말아야 하고, 단지 뷰와 관련된 기능만 포함해야 함.


2. 징후 및 결과 (Symptoms and Consequences)
  • 커스텀 태그에 비즈니스 로직을 정의할 경우, 비즈니스 로직은 웹 클라이언트가 아닌 다른 클라이언트에서 쉽게 사용할 수 없음.
  • 모델과 컨트롤러의 기능을 수행하는 커스텀 태그는 많은 어트리뷰트를 필요로 하는데, 이것은 다루기가 어려움.
  • 커스텀 태그는 일반 자바 클래스보다 생성하고 디버깅하고 관리하기가 약간 더 복잡함. 이와 같은 복잡성은 JSP 페이지를 좀더 간단하고 쉽게 작성할 수 있을 경우에 가치가 있지만, 그렇지 않을 경우에는 오히려 일반 자바 클래스가 더 올바른 선택이 될것 임.

3. 리팩토링된 해결방안 (Refactored Solutions)
Service to Worker 패턴을 엄격하게 적용함으로써, 적절하지 않은 상화에서도 커스텀 태그를 만들고자 하는 유혹을 거의 받지 않을 수 있음.


4. 관련 패턴 (Related Patterns)
  • Service to Worker
이올린에 북마크하기

happyness Programming/J2EE Patterns ,

2007/05/27 19:24 2007/05/27 19:24
[로그인][오픈아이디란?]

프리젠테이션(Presentation) 티어 안티 패턴 - Embedded Navigational Information

2007/05/27 19:12
1. 문제점
Embedded Navigational Information 안티 패턴은 JSP 페이지에 URL 주소를 임베딩 시킴으로써 발생하는 문제점에 대해 지적하고 있는 패턴으로, 이 패턴이 지적하고 있는 문제점을 살펴보면 다음과 같음.

JSP 페이지 내에 존재하는 컨텐츠는 하이퍼 링크 또는 버튼 등을 눌렀을 때 억세스하기 위한 위치 정보인 URL을 보통 하나 이상 포함하고 있음. 또한 JSP 페이지는 JSP 페이지 파일 이름 또는 HTML 파일 이름을 포함함.
이들 파일 이름과 URL 정보가 바뀔 경우, 이들 정보를 사용하고 잇는 모든 JSP 페이지가 수정되어야 함. 많은 JSP 페이지에서 사용하고 있는 파일 이름을 수정하는 것은 어려운 일이고, 또한 링크가 적절히 수정되지 않을 경우, 어플리케이션 동작시 사용자 링크를 선택했을 때 억세스에 실해하는 일이 발생함.


2. 징후 및 결과 (Symptoms and Consequences)
  • 사요자가 에러 페이지를 수신하는 경우가 발생.
  • 어플리케이션 플로우를 수정하기가 어려움.

3. 리팩토링된 해결방난 (Refactored Solutions)
Front Controller 패턴을 사용함으로써, 하이퍼링크와 버튼을 눌렀을 때 원하는 자원에 억세스하기 위해 필요한 URL 정보를 모두 하나의 Front Controller Servlet으로 지정할 수 있음. 따라서 하이퍼 링크와 버튼을 눌렀을 때 항상 Front Controller Servlet을 억세스하게 됨.


4. 관련 패턴 (Related Patterns)
  • Front Controller
이올린에 북마크하기

happyness Programming/J2EE Patterns ,

2007/05/27 19:12 2007/05/27 19:12
[로그인][오픈아이디란?]

프리젠테이션(Presentation) 티어 안티 패턴 - Including Common Functionality in Every Servlet

2007/05/27 19:02
1. 문제점
Including Common Functionality in Every Servlet 안티 패턴은 공통적으로 필요로 하는 기능을 재사용하고자 할 때 필터를 사용하지 않는 것에 대해 기술하고 있는 패턴으로, 이 패턴이 지적하고 있는 문제점을 살펴보면 다음과 같음.

선처리와 후처리가 각 서블릿의 서비스 메소드 형태로 구현되거나 호출됨. 이것은 Java Servlet 2.3 이전 환경에는 좋은 솔루션이라 할수 있음.
그러나, 이 패턴은 Java Servlet 2.3 컨테이너가 소개된 이후 안티 패턴이 되었음.


2. 징후 및 결과 (Symptoms and Consequences)
  • 선처리와 후처리는 프로그램적인 방식으로, 서블릿에 추가 또는 제거될 수 있어야 함.
  • 서블릿의 응집력이 떨어짐.

3. 리팩토링된 해결방안 (Refactored Solutions)
Intercepting Filter J2EE 패턴을 적용해야 함으로써 선처리와 후처리 작업이 필터에 구성될 수 있도록 함.
시스템이 클라이언트에 의해 직접 억세스 되는 JSP 페이지를 포함하고 있을 경우에도, 똑같이 Intercepting Filter J2EE 패턴을 적용할 수 있음.


4. 관련 패턴 (Related Patterns)
  • Intercepting Filter
이올린에 북마크하기

happyness Programming/J2EE Patterns ,

2007/05/27 19:02 2007/05/27 19:02
[로그인][오픈아이디란?]

프리젠테이션(Presentation) 티어 안티 패턴

2007/05/27 18:50
1. 개요
프리젠테이션 티어 안티 패턴은 J2EE 플랫폼 프리젠테이션 티어 기술의 바람직하지 못한 사용에 대해 소개하고 있음. 이들 안티 패턴들은 프리젠테이션 티어에서 잘못된 디자인을 피하고, 좋은 디자인을 찾기 위해 프리젠테이션 티어 J2EE 패턴과 함께 사용함.


2. 종류
  • Including Common Funtionality in Every Servlet AntiPattern
    공통적으로 필요로 하는 기능을 재사용하기 위해 필터를 사용하고 있지 않음.
  • Embedded Naviagtional Information AntiPattern
    JSP 페이지에 URL 주소를 직접 사용하고 있음.
  • Ad Lib TagLibs AntiPattern
    비즈니스 또는 제어 기능을 위해 커스텀 태그를 사용.
이올린에 북마크하기

happyness Programming/J2EE Patterns

2007/05/27 18:50 2007/05/27 18:50
[로그인][오픈아이디란?]

비즈니스(Business) 티어 안티 패턴 - Contenvtional State

2007/05/27 18:43
1. 문제점
Contenvtional State 안티 패턴은 너무 많은 세션 상태를 관리할 경우 발생하는 문제점들에 대해 기술하고 있는 패턴으로, 이 패턴이 지적하고 있는 문제점을 살펴보면 다음과 같음.

많은 엔터프라이즈 어플리케이션에서 세션 상태 유지작업을 필요로 함.


2. 징후 및 결과 (Symptoms and Consequences)
  • 상태 정보가 하나의 티어에서 다른 티어로 패스됨에 따라 시스템의 퍼포먼스가 떨어지고 또는 상태저장에 따른 메모리 오버헤드가 증가함.
  • 모든 클라이언트의 상태 정보를 저장함에 따라 시스템 확장성이 떨어짐.

3. 리팩토링된 해결방안 (Refactored Solutions)
가능한 한 작업이 상태정보를 유지하지 않아도 되도록 만들어야 함. 또한 작업 수행시 실질적으로 관리해야 할 상태정보가 얼마나 되는지에 대해서도 정확히 파악하여 관리해야 함.
이올린에 북마크하기

happyness Programming/J2EE Patterns ,

2007/05/27 18:43 2007/05/27 18:43
[로그인][오픈아이디란?]

비즈니스(Business) 티어 안티 패턴 - Mirage

2007/05/27 18:36
1. 문제점
Mirage 안티 패턴은 CMP가 더 적절한 상황에서 BMP를 사용함으로써 발생하는 문제점들에 대해 기술하고 있는 패턴으로, 이 패턴이 지적하고 있는 문제점을 살펴보면 다음과 같음.

EJB 1.x 서버환경에서는 BMP를 CMP보다 더 많이 선호했음. EJB 1.x 서버에서 제공되는 CMP의 기능이 그렇게 견고하지 않았음. 그러나 EJB 2.0 서버에서는 CMP의 기능이 상당히 많이 개선되었음. EJB 2.0 서버에서의 CMP 기능은 관계형 데이터베이스를 사용하는 많은 어플리케이션을 지원할 수 있고, 관계형 데이터 베이스가 아니더라도 가능함.

CMP의 이점
  • 데이터 개싱, lazy loading, 기타 다른 서버 최적화작업을 통해 CMP는 BMP보다 퍼포먼스가 더 좋을 수 있음.
  • CMP를 사용할 경우 빈에 직접 SQL 코드를 작성하지 않기 때문에 BMP보다 이식성이 더 높음.
  • CMP를 사용할 경우 개발이 더 쉽고, 구현 시 코드 라인 수를 많이 줄일 수 있음.
  • CMP 2.0은 CMR(Container Managed Relationships)을 제공.

2. 징후 및 결과 (Symptoms and Consequences)
  • 불필요한 많은 개발과 유지보수 노력을 필요로 함.
  • 엔티티 빈이 낼 수 있는 성능만큼의 성능을 내지 못하고 있음.

3. 리팩토링된 해결방안 (Refactored Solutions)
가능한 한, BMP 대신 CMP 사용을 고래해야 함. CMP 사용이 가능할 경우에는 CMP를 사용해야함. 또한 사용하고자 하는 서버가 CMP 기능을 얼마나 지원하고 있는지를 체크해야 함. 더 나아가, 서버가 제공하는 CMP 기능이 BMP 보다 더 좋은지를 판단하기 위해 직접 퍼포먼스 테스트를 수행해야 함.
이올린에 북마크하기

happyness Programming/J2EE Patterns ,

2007/05/27 18:36 2007/05/27 18:36
[로그인][오픈아이디란?]

비즈니스(Business) 티어 안티 패턴 - Accesses Entities Directly

2007/05/27 18:20
1. 문제점
Accesses Entities Directly 안티 패턴은 프리젠테이션 티어 콤포넌트가 직접 엔티티 빈을 억세스할 때 발생할 수 있는 문제점들에 대해 기술하고 있는 패턴으로, 이 패턴이 지적하고 있는 문제점을 살펴보면 다음과 같음.

서슬릿과 JSP 프리젠테이션 티어 콤포넌트가 직접 엔티티 빈을 억세스 할 경우, 몇가지 심각한 문제가 발생할 수 있음.
프리젠테이션 티어와 비즈니스 티어가 서로 떨어져 있을 경우, 리모트 호출 횟수가 많아짐으로써 퍼포먼스가 떨어지게 됨. 또한 프리젠테이션 티어 콤포넌트는 엔티티 빈을 생성해서, 빈이 제공하는 다양한 메소드를 호출하고, 트랜젝션 제어 또한 수행해야 함.
지금 프레젠테이션 티어 콤포넌트가 하고 있는 이와 같은 작업은 실제로는 비즈니스 티어가 수행해야 할 책임임.


2. 징후 및 결과 (Symptoms and Consequences)
  • 너무 많은 리모트 호출 횟수로 인해 퍼포먼스가 떨어짐
  • 프리젠테이션 티어 개발자는 비즈니스 티어 콤포넌트에 대해 많은 지식을 자세히 알고 있어야 함.

3. 리팩토링된 해결방안 (Refactored Solutions)
Session Facade 패턴을 사용함으로써, 프리젠테이션 티어 콤포넌트와 비즈니스 엔티티 콤포넌트간 커플링을 없앨 수 있음.


4. 관련 패턴 (Related Patterns)
  • Session Facade
    Seesion Facade 패펀을 이용해 프리젠테이션 티어 콤포넌트와 비즈니스 티어 콤포넌트간 커플링을 줄일 수 있고, 프리젠테이션 티어 콤포넌트는 비즈니스 티어 콤포넌트에 대한 상세 정보 없이도 쉽게 사용할 수 있음.
이올린에 북마크하기

happyness Programming/J2EE Patterns ,

2007/05/27 18:20 2007/05/27 18:20
[로그인][오픈아이디란?]

비즈니스(Business) 티어 안티 패턴 - Local and Remote Interface Simultaneously

2007/05/27 18:00
1. 문제점
Local and Remote Interface Simultaneously 안티 패턴은 빈을 위해 로컬과 리모트 인터페이스를 제공함으로써 발생하는 문제점에 대해 지적하고 있는 패턴으로, 이 패턴이 지적하고 있는 문제점을 살펴보면 다음과 같음.

EJB 2.0에서는 콤포넌트 작성시 로컬 인터페이스를 제공할 것인지, 리모트 인터페이스를 제공할 것인지, 아니면 둘 다 제공할 것인지를 선택할 수 있음.

로컬과 리모트 인터페이스 둘 다 제공할 경우, 타입 케스팅을 할 때 인터페이스 이름이 필요로하므로 클라이언트 프로그래머는 어떤 인터페이스를 사용해야 할지 선택해야 함. 그러나, 로컬과 리모트 인터페이스 모두 동일한 인터페이스를 상속 받고 있다면, 어떤 인터페이스를 사용해야 하는지 결정할 필요가 없음. 디플로이 디스크립터에 JNDI 네임 바인딩을 조정함으로써, 로컬 인터페이스를 사용하든 리모트 인터페이스를 사용하든 상관없이 클라이언트 코드를 같게 작성할 수 있으나 아래와 같은 단점을 가짐.
  • 동일한 인터페이스 상속
    동일한 인터페이스를 상속 받을 경우, 로컬 인터페이스에 선언되는 메소드들은 RemoteException을 throws 하도록 선언해야 함. 따라서, 클라이언트가 로컬 인터페이스를 사용할 지라도 RemoteException을 catch 해야 함.
  • 리모트 환경과 로컬 환경의 데이터 패스 방식
    리모트 환경과 로컬 환경에서 메소드 파라메터를 통해 데이터를 패스하는 방식이 다름. 리모트 환경에서는 메소느 파라메터를 Pass-By-Value 방식으로 전달하고, 로컬 환경에서는 메소드 파라메터를 Pass-By-Reference 방식으로 전달함.
    메소드 파라메터를 전달할 때 Pass-By-Reference 방식으로 전달할 경우 부작용 현상이 발생할 수 있음. 이와 같은 부작용을 피하기 위해, 모든 메소드 파라메터는 Pass-By-Value로 전달되도록 할 수 있음. 그러나, 이와 같은 작업은 리모트 환경에서는 노력과 시간이 낭비됨.
  • 리모트 인터페이스와 로컬 인터페이스의 설계
    리모트 인터페이스는 로컬 인터페이스와 다르게 설계되어야 함. 특히, 리모트 인터페이스는 Coarse-Grained하게 설계되어야 하는 반면, 로컬 인터페이스는 Fine-Grained하게 설계되어햐 함.
  • 콤포넌트 결정
    콤포넌트를 로컬 콤포넌트로 할 것인지, 리모트 콤포넌트를 할 것인지에 대한 결정은 퍼포먼스에 많은 영향을 주는 부분이기 때문에 중요한 디자인 결정 중 하나임. 따라서, 리모트 인터페이스를 사용할 것인지, 로컬 인터페이스를 사용할 것인지에 대해서는 신중하게 결정함으로써, 한번 결정된 사항을 왔다 갔다 바꾸지 않도록 해야 함.

2. 징후 및 결과 (Symptoms and Consequences)
  • 로컬 억세스와 리모트 억세스에 대한 잘못된 선택으로 인해 시스템의 퍼포먼스가 늦음.
  • 로컬 억세스와 리모트 억세스 코드가 적절하게 설계되지 않음으로써 예상치 못한 부작용이 발생함.

3. 리팩토링된 해결방안 (Refactored Solutions)
리모트 영역을 신중하게 결정하고 나서, 이 결정사항에 따라 로컬 또는 리모트 인터페이스를 사용. 일반적으로, 리모트 영역의 수가 많을 경우 퍼포먼스는 떨어짐. 따러서, 콤포넌트 레이어의 어디를 정말 물리적으로 분리시킬 필요가 있는 지를 결정해야 함.
이올린에 북마크하기

happyness Programming/J2EE Patterns ,

2007/05/27 18:00 2007/05/27 18:00
[로그인][오픈아이디란?]

비즈니스(Business) 티어 안티 패턴 - Sledgehammer for a Fly

2007/05/27 17:40
1. 문제점
Sledgehammer for a Fly 안티 패턴은 EJB 기술이 제공하는 서비스가 필요하지 않은 상황에서도 EJB 기술을 사용함으로써 발생하는 문제점을 기술하고 있는 패턴으로, 이 패턴이 지적하고 있는 문제점을 살펴보면 다음과 같음.

EJB 콤포넌트는 많은 이점과 서비스들을 제공하지만, 그와 같은 이점과 서비스들은 오버헤드를 비롯하여 복잡도, 개발시간, 유지시간 등을 증가시킴.
EJB 콤포넌트에서 제공하는 서비스가 필요할 경우, 증가되는 오버헤드와 복잡도, 개발시간은 EJB 콤포넌트에서 제공하는 서비스를 직접 개발하는 드는 비용과 비교했을 때 훨씩 적음. 그러나, EJB 콤포넌트에서 제공하는 서비스가 필요하지 않을 경우, 사용하지도 않는 서비스로 인해 많은 비용을 지불해야 함.


2. 징후 및 결과 (Symptoms and Consequence)
  • 개발하고자 하는 시스템의 복잡도가 증가하고 또한 개발 효율성도 떨어짐.
  • 작업을 수행하기 위해 필요한 코드라인 및 클래스와 인터페이스의 수가 증가.
  • 퍼포먼스가 느려짐.

3. 리팩토링된 해결방안 (Refactored Solutions)
시스템 요구사항을 주의 깊게 살펴봄.
어플리케이션이 높은 확장성을 필요로 하지 않고, 분산 트랜잭션도 필요로 하지 않고, 다른 복잡한 문제점들을 가지고 있지 않을 경우, 일반적인 자바 오브젝트를 사요하는 것이 더 좋을 것임.
EJB 콤포넌트를 사용할 경우에도 EJB 콤포넌트와 일반 자바 오브젝트를 같이 사용해야 함.
이올린에 북마크하기

happyness Programming/J2EE Patterns ,

2007/05/27 17:40 2007/05/27 17:40
[로그인][오픈아이디란?]

비즈니스(Business) 티어 안티 패턴

2007/05/27 17:32
1. 개요
비즈니스 티어 안티 패턴은 J2EE 플랫폼 비즈니스 티어 기술의 바람직하지 못한 사용에 대해 소개하고 있음. 이들 안티 패턴들은 비즈니스 티어에서 잘못된 디자인을 피하고, 좋은 디자인을 찾기 위해 비즈니스 티어 J2EE 패턴과 함께 사용


2. 종류
  • Sledgehammer for a Fly AntiPattern
    EJB 기술이 필요없는 상황에서도 EJB 기술을 사용.
  • Local and Remote Interface Simultaneously AntiPattern
    클라이언트가 빈을 억세스할 때 사용할 로컬과 리모트 인터페이스를 모두 제공함.
  • Accesses Entities Directly AntiPattern
    프리젠테이션 티어 콤포넌트가 직접 엔티티 빈을 억세스하고 있음.
  • Mirage AntiPattern
    CMP 사용이 더 적절한 상황에서 BMP를 사용하고 있음.
  • Conversational State AntiPattern
    세션에 필요한 것보다 더 많은 상태를 저장하고 있음.
이올린에 북마크하기

happyness Programming/J2EE Patterns

2007/05/27 17:32 2007/05/27 17:32
[로그인][오픈아이디란?]