2016년 7월 12일 화요일

디자인 패턴 - #4 Business Tier Patterns

#4 Business Tier Patterns

  • Business Delegate
  • Value Object ( Transfer Object )
  • Session Facade
  • Aggregate Entity ( Composite Entity )
  • Value Object Assembler
  • Value List Handler
  • Service Locator


Business Delegate

  • 패턴명 : Business Delegate
  • 적용 문제
    • 분산 app에서 원격의 component들을 presentation 층에서 직접 접근 할 수 있 수 있는데, 이때
      원격 component들이 수정되면 프리젠테이션 층도 반영 되어야 한다.
  • 해결방안
    • 프리젠테이션 층에서 비즈니스 컴포넌트들을 분리하여 중재자 역할 수행
    • Business Delegate은 분산컴포넌트를 찾고, 예외처리 , View를 선택
  • 적용 결과
    • 의존성 감소
    • 유지보수 증대
    • UI가 간단 정형화

Value Object

  • 패턴명 : Value Object ( Transfer Object )
  • 적용 문제
    • 분산 애플리케이션 환경하에서는 Data 전송을 위한 네트워크 사용이 빈번하게 발생됨
    • 하나의 attribute 값을 전송하기 위해서 다수의 메소드 호출이 발생이 될 수 있음
  • 해결방안
    • 전송해야 하는 attribute들을 저장할 수 있는 Object를 이용
  • 적용 결과
    • 네트워크 Traffic 감소

Session Facade

  • 패턴명 : Session Facade
  • 적용 문제
  • 해결방안
  • 적용 결과
세션 Facade 사용하지 X
세션 Facade 사용함

Aggregate Entity ( Composite Entity )

  • 패턴명 : Aggregate Entity ( Composite Entity )
  • 적용 문제
    • EntityBean는 데이터 베이스의 하나인 record를 표현함. 이때 일반적인 데이터 접근 방법은
      fine-grained
  • 해결방안
    • 종속관계가 있는 비지니스 엔티티를 coarse-grained로 해결
    • 클라이언트에 대한 인터페이스는 coarse-grained로 유지하고, 종속적인 내부관계 에서는 fine-grained로 상호작용한다.
    • EJB1.1 에서는 종속객체는 일반적인 자바클래스로 구현 했으나 EJB2.0 스펙에서는 로컬 EntityBean으로 구현
  • 적용 결과
    • 응답속도 개선
    • 프로그래밍 모델을 단순화
    • EJB 클래스와 코드 감소

Value Object Assembler

  • 패턴명 : Value Object Assembler
  • 적용 문제
    • J2EE의 분산환경에서 client가 server상의 value object를 접근하고자 하면 client는 모든 원격의
      value object를 개별적으로 접근해야 한다.
    • 위 경우 성능 저하, 복잡성 증가, 의존도 증가의 문제가 발생
  • 해결방안
    • 복잡한 데이터를 표현하는 value objet를 포함하는 value object assember를 이용하여 coarse-grained로 동작
  • 적용 결과
    • 비지니스 로직 분리
    • Client와 비즈니스 모델과의 의존도 감소
    • 네트워크 성능 향상
    • Client 복잡성 감소

Value List Handler

  • 패턴명 : Value List Handler
  • 적용 문제
    • J2EE는 일반적으로 검색기능을 포함하며 대량의 데이터를 검색하고 결과를 보여 줌
    • 이 때 대량의 결과를 데이터를 클라이언트에게 리턴하면 클라이언트는 데이터를 추출하는데
      많은 시간이 필요
  • 해결방안
    • 클라이언트에게 대량의 데이터를 한번에 리턴하기 보다는 적은양의 데이트를 여러 번에 걸쳐
      반복적으로 리턴해주는 효율적인 방법을 제공.
    • DAO를 통해 추출된 데이터의 리스트를 캐싱하고 클라이언트에게 데이터를 리턴한다.
      클라이언트는 한페이지만의 리스트 데이터를 볼 수 있다.
  • 적용 결과
    • EJB의 finder 메소드의 overhead를 감소
    • 네트워크 성능 향상

Service Locator

  • 패턴명 : Service Locator
  • 적용 문제
    • JNDI의 자원을 다수의 클라이언트가 접근하고자 할 때 lookup코드가 중복되고 성능도 저하
  • 해결방안
    • 서비스 객체를 찾고, 제어의 포인트를 집중화 시켜서 코드 중복 및 성능 향상
  • 적용 결과
    • 코드 중복 감소
    • 일관된 접근법 제공
    • 성능 향상

출처 - OJTKOREA(링크)

디자인 패턴 - #3 Presentation Tier Patterns

#3 Presentation Tier Patterns

  • Decorating Filter
  • Front Controller
  • View Helper
  • Composite View
  • Service To Worker
  • Dispatcher View


Decorating Filter

  • Pattern name : Decorating Filter (Intercepting Filter)
  • Problem : 웹 애플리케이션의 Main 프로세스가 처리되기 전에 선처리 작업으로서 실행해야 하는 작업이 발생되는 경우
    • 클라이언트 IP 주소 신뢰성 여부 확인
    • 데이터 인코딩(encoding) 작업
    • 클라이언트의 유효한 인증 여부 확인
    • 특정 브라우저를 지원가능 여부 확인
  • Solution : Main 프로세스 코드 변경 없이 표준방법으로 공통적인 서비스를 처리
    • GoF의 Decrator 패턴
    • Servelet 2.3의 Filter API 이용
    • 스트러츠 경우 Request 객체를 Override 함
  • Consequence
    • 재사용성 증가
    • 유지보수 용이
    • 전처리 코드의 집중화로 확장용

Front Controller

  • Pattern name : Front Controller
    • MVC 모델에서 C에 해당함.
    • 예제 #1(영문) : 링크
  • Problem :
    • 웹 애플리케이션 시스템은 view 관리, navigation 관리등과 같은 처리를 통합처리 할 필요가 있음
    • 통합처리 않는 시스템의 문제점
      • 각각 개별적인 요청에 의한 view 처리에 대한 중복코드 발생
      • view 및 내용이 혼합되어 복잡
      • 처리 프로세스의 복잡성 때문에 유지보수 어려움
  • Solution
    • 모든 요청(링크,전송) 의 진입점을 담당하는 controller 역할
    • controller은 인증과 권한 기능 및 에러처리 기능을 포함할 수 있음
    • 요청에 해당하는 실제적인 비즈니스 처리를 담당하는 곳으로 처러를 위임 하거나 또는 알맞은 view를 선택
  • Consequence
    • Control 기능의 집중화
    • 보안 기능 강화
    • 재상용성 증대
    • 사용자 Tracking 과 logging
    • 에러처리 및 valiation 체크

View Helper

  • 패턴명 : View Helper
    • jsp 코드에 자바 코드가 없도록 하는 것이 목적^^
    • 예제 #1 : oracle
  • 적용 문제
    • Presentation Tier는 매우 자주 변경되는 특징을 갖음
    • View안에 비지니스 로직과 프리젠테이션 로직의 혼합으로 유지보수가 어렵다
    • 비지니스 로직과 프리젠테이션을 분리하고자 할때
  • 해결방안
    • View(jsp) 컴포너트에는 Formatting code만 구현 나머지는 비즈니스 코드는 Helper 클래스를 이용
    • 대표적인 help 클래스 : JavaBeans 혹은 커스텀 태그
  • 적용 결과
    • 웹 애플리케이션의 역할 분담이 명확해짐
    • 재사용과 유지보수를 좋아짐

Composite View

  • 패턴명 : Composite View
  • 적용 문제
    • 복잡한 웹 페이지들은 하나의 페이지에서도 많은 Data와 Subview들로 구성되어 있는 경우
    • 요청에 따른 페이지 변경 시에도 중복되는 subview들이 있으며 이 subview들을 매 페이지마다 동일하게 구현
  • 해결방안
    • 중복코드를 위한 템플릿(template)를 작성
    • 템플릿에서 중복되는 subview를 인스턴스화 함
  • 적용 결과
    • subview들의 재사용 증가
    • 유지보수 감소

Service To Worker

  • 패턴명 : Service To Worker
    • MVC : V , C
    • 예제 #1(영문) : 링크  
  • 적용 문제
    • FrontController 문제 와 View Helper 문제 혼합
  • 해결방안
    • 요청 처리를 모듈화 시키고 view 관리를 담당하는 Dispatcher를 이용
  • 적용 결과
    • 업무 분리 명확
    • 재사용성 증가
    • 유지보수 감소

Dispatcher View

  • 패턴명 : Dispatcher View
  • 적용 문제
    • FrontController 문제 와 View Helper 문제 혼합
  • 해결방안
    • 비즈니스 처리 요청을 controller가 아닌 view에서 처리
  • 적용 결과
    • 업무 분리 명확
    • 재사용성 증가
    • 유지보수 감소
출처 - OJTKOREA(링크)