화요일, 5월 7
Shadow

#044 패턴과 스트럿츠

엔트프아이즈 디자인 패턴

성능과 다수의 “~성”
가장 중요한 3가지 비기능적인 요구사항 입니다.
1. 성능
2. 모듈화
3. 유연성, 유지보수성, 확장성

우선 용어부터 정의하죠
ㅇ 인터페이스를 사용하라
인터페이스란 두 객체간의 일종의 계약이라고 말할수 있습니다. 하나의 ㅋ르래스가 어떤 인터페이스를 구현했다면 다음과 같은 의미가 있죠 내가 만든 객체는 당신이 하는 얘기를 이해할수 있어요. 인터페이스가 가지는 또 하나 장점으로 다형성을 들수 있습니다. 다수의 클래스가 한개의 인터페이스를 동시에 구현한 경우 동일 인터페이스라면 어떤 클래스도 호출할수 있지요 예를들어 웹 컨테이너는 Servlet 인터페이스를 구현한 어떤 컴포넌트도 사용할수 있는 것처럼요

ㅇ관심영역의 분리 및 응집성
소프트웨어의 특정 기능만 특화시켜 컴포넌트화 하면 개발하기도 쉽고 유지보수 하기 편하며, 재사용성도 높일수 있지요 고나심 영역을 분리하게 되면 자연스럽게 응집도는 높아지기 마련이죠 응집도란 하나의 클래스가 하나의 단위 작업 목적에 얼마나 충실한가 하는정도를 나타냅니다.

ㅇ복잡성을 숨겨라
복잡성을 숨긴다는것 관심 영역의 분리는 사실 같은 문제기도 합니다. 예를 들어 시스템이 검색 서비스를 사용해야 하는 경우, 실제 구현 부분을 하나의 컴포넌트로 구현하여 다른 모든 컴포넌트들이 이를 사용하게 하는 방식이 최선일겁니다.

디자인 원식, 이어서
느슨한 결합도
객체지향 시스템은 그 본성상 객체 간 대화로 이루어져 있습니다. 이 대화에 인터페이스를 이요하면 두개의 클래스가 서로 대화하기 위하여 서로간의 알아야 할것의 수를 줄여줍니다.

원격 프록시
웹사이트가 커져감에 따라 하나의 거대한 서버, 즉 사이즈를 늘리기 보다 새로운 서버를 도입하여 문제를 푸는 것이 현실입니다. 이것이 가능하려면 서로 다른 서버 위에 서로 다른 힙 영역에서 돌아가는 자바 객체들이 서로 통신해야 한다는 말입니다.

선언적인 제어를 많이 사용하라
애플리케이션을 선언적으로 제어하는 방식은 J2EE컨테이너의 막강한 능력이라고 말할수 있습니다. 선언적인 제어는 애플리케이션 배포 서술자에서 대부분 이루어 집니다.

원격 모델 컴포넌트를 지원하기 위한 패턴
클라이언트가 곡개 정보를 요구할때
1. 고객정보에 대한 요청을 접수 받으면 컴트롤러는 레거시 데이터베이스에 대하여 JDBC호출을 하는 고객관리 서비스 컴포넌트를 호출합니다. 그 다음 Customer 빈을 만들어 데이터베이스로 부터 읽어온 고객정보를 설정합니다.
2. 컨트롤러는 request 객체에 속성으로 Customer 빈참조를 추가합니다.
3. 컨트롤러는 이제 뷰인 JSP로 요청을 넘깁니다. JSP는 request 객체에 들어있는 Customer빈에 대한 참조를 사용할수 있게 됐죠
4. JSP는 EL을 사용하여 Customer빈의 프로퍼티 정보를 뽑아내어 페이지를 완성합니다.

RMI에 대해 조금만 살펴보죠
서버측 RMI 사용을 위한 4단계
1. 원격 인터페이스를 만듭니다 getCustData()와 같은 메소드 규약을 정의하는 곳입니다. 스텁과 실제 모델서비스가 이 인터페이스를 구현합니다.
2. 원격 구현을 생성합니다. 원격 구현이 무엇이냐 하면 모델 서버상에 존재하는 실제 모델 객체를 말합니다. 여기엔 JNDI나 RMI 레지스트리와 같은 곳에 모델을 등록하는 코드가 포함됩니다.
3. 스텁과 스켈레톤을 생성하니다. RMI는 프록시를 생성하는 rmic라는 컴파일러를 제공하무로 이를 이용하면 됩니다.
4. 모델 서비스를 시작합니다.

비즈니스 티어 패턴 : 한눈에 살펴보기
지금까지 살펴본 비즈니스 티어 패턴을 요역하여 하나의 다이어그램으로 만들어 봤습니다. 여기에는 비즈니스 델리케이트, 서비스 로케이터, 트랜스퍼 오브젝트가 모두 들어있스니다.
A6 단계 리뷰
1. 서비스를 JNDI에 등록합니다.
2. 비즈니스 델리게이트와 서비스 로케이터를 사용하여, JNDI에서 고객관리 스탭을 얻습니다.
3. 비즈니스 델리케이트와 스탭을 사용하여  Customer 빈을 얻습니다. 여기서 Customer 빈은 트랜스퍼 오브젝트이죠. 이 스텁 참조를 컨트롤러로 리턴합니다.
4. request 에 빈 참조를 추가합니다.
5. 컨트롤러는 요청을 JSP로 넘깁니다. JSP는 request객체에서 Customer 트랜스퍼 오브젝트 참조를 얻습니다.
6. JPS는 원래 요청한 의도대로 필요한Customer 트랜스퍼 오브젝트의 프로퍼티 정보를 EL로 추출하여 페이지를 완성합니다.

MVC 패턴
컨트롤러 :  request에서 사용자가 입력한 정보를 추출하여, 이것이 모델ㅔ 어떤 작용을 하라는 건지 파악합니다. 모델에게 자신의 데이터를 수정하라고 지시하던지, 뷰가 사용할수있게 모델정보를 request에 추가하든지 한다음 요청을 JSP로 넘기죠
모델 : 실제 비즈니스 정보 및 비즈니스 로직이 들어있죠 즉 정보를 수정/접근하는 규칙을 알고 있다는 말입니다. 장바구니 안에 들어있는 컨텐츠는 MVC에서 모델의 한 종류죠 이부분이 데이터베이스와 대화하는 애플리케이션입니다.
뷰 : 프리젠테이션의 역할을 담당하죠. 컨트롤러로 부터 모델 종보를 넘겨받습니다.

MVC 컨트롤러를 한번 보죠
일반 MVC 컨트롤러 의사 코드
public class ControllerServlet extends HttpServlet{
public void doPost(request, response){
Stirng c= req.getparameter(“startDate”);
//request 파라미터를 다루는 부분
// 모델을 다루는 부분
//뷰를 다루는 부분
}
}

—————————————————————비즈니스 델리게이트 특징
웹 애플리케이션 모델 컴포넌트가 원격인 호나경에 웹 티어 컨트롤러를 보호하려면 비즈니스 델리게이트를 사용하세요
ㅇ 프록시로 행동함, 원격 서비스의 인터페이스 구현
ㅇ 원격 서비스와 통신을 초기화 함
ㅇ 통신시 상세사항 및 예외사항을 처리함
ㅇ 요청을 해석하여, 이를 비즈니스 서비스로 넘겨줌
ㅇ 응답을 해석하고, 이를 컨트롤러 컴포넌트로 넘겨줌.
ㅇ 상세한 원격 컴퓨넌트 검색 및 통신을 처리함으로 해서 컨트롤러를 더욱 응집성 있는 컴포넌트로 만들어 줌

—————————————————————비즈니스 델리게이트 원칙
ㅇ 비즈니스 델리게이트 다음에 기초를 둠 :
– 복잡성을 숨김
– 인터페이스로 코딩
– 느슨한 결함
– 관심영역 분리
ㅇ 비즈니스 티어 변경으로 인하여 웹 티어가 영향을 받는 것을 최소화
ㅇ 두 티어간 결합 정도를 낮춤
ㅇ 애플리케이션에 새로운 계층을 하나 추가함으로 해서 복잡도를 높이는 결과
ㅇ 비즈니스 델리게이트 메소드 호출은 네트워크 트래픽을 최소화하기위해 큰 단위 호출이 바람직함

서비스 로케이터
레지스트리 검색을 위한 서비스 로케이터 패턴을 사용합니다. 이를 사용하면 JNDI 검색을 해야 하는 모든 컴포넌트를 아주 단순하게 유지 할수 있습니다.
—————————————————————서비스 로케이터 특징
ㅇ Initialcontext 객체를 얻습니다.
ㅇ 레지스트리 검색을 수행함
ㅇ 상세한 통신 사항이나 예외사항을 처리함
ㅇ 한번 읽은 객체 참조는 캐시 해 두어 성능을 향상시킴
ㅇ 다음과 같은 다양한 레시스트리와 작업함 : JNDI, RMI, UDDI,COS 네이밍
—————————————————————서비스 로케이터 원리
ㅇ 서비스 로케이ㅓ는 다음에 기초를 둠
– 복잡성을 숨긴다.
– 관심 영역의 분리
ㅇ 원격 컴포넌트가 위치를 바꾸거나 컨테이너를 바꿀경우 웹 티어에 미치는 영향을 최소화함
ㅇ 티어 간 결합 정도를 낮춤

트랜스퍼 오브젝트
잘게 나누어진 원격 컴포넌트를 대신하는 지역 클래스를 제공하여 네트워크 트래픽을 감소하는데 트랜스퍼 오브젝트를 사용하세요
—————————————————————전송 객체 기능
ㅇ 원격 엔티티에 대한 지역 대표 객체를 제공함
ㅇ 네트워크 트래픽을 최소화
ㅇ 자바 빈 명명법을 따름으로 해서 기타 객체들이 쉽게 접근할수 있도록 함
ㅇ 네트워크를 가로질러 전송될수 있도록 직력화된 객체로 구현함
ㅇ 일반적으로 뷰 컴포넌트에서 쉽게 접근할수 있도록 만듦

인터셉팅 필터
서블릿으로 보내지는 요청을 수정하기 위하여 또는 사용자에게 보낼 응답을 수정하기 위하여 인터셉팅 필터를 사용하세요
—————————————————————인터셉팅 필터 기능
ㅇ 서블릿에 도착하기 전 요청을 낚아채서 수정할수 있습니다.
ㅇ 응답이 클라이언트로 넘가가기 전 이를 낚아채서 수정할수 있습니다.
ㅇ 필터는 DD를 사용하여 선언적으로 배포할수 있습니다.
ㅇ 컨테이너가 필터 생명주기를 관리합니다.
ㅇ 필터는 컨테이너 콜백 메소드를 구현해야 합니다.
—————————————————————인터셉팅 필터 원칙
ㅇ 인터셉팅 필터는 다음에 기초를 둠 :
– 응집력
– 느슨한 결합
– 선언적인 제어 능력
ㅇ 선언적으로 필터를 설정할수 있기에 임시로 사용하거나 아니면 영구적으로 사용토록 쉽게 설정 가능함
ㅇ 선언적으로 필터를 설정할수 있기에 순서대로 실행되는것도 쉽게 수정할수 있음

모델 뷰 컨트롤러(MVC)
애플리케이션을 논리적인 구조로 만드렁 세가지 기본 유형, 모델, 뷰, 컨트롤러로 코드를 관리하는데 MVC패턴을 사용하세요 이 방식은 각 컴포넌트의 응집성과 재사용성을 높입니다. 특히 모델 컴포넌트가 그러하죠
—————————————————————모델, 뷰, 컨트롤러 특징
ㅇ 컨트롤러와 모델과는 독립적으로 뷰를 수정할수 잇습니다.
ㅇ 모델 컴포넌트는 뷰와 컨트롤러 컴포넌트로부터 데이터 구조와 같은 내부적인 상세한 사항을 숨깁니다.
ㅇ 모델에 인터페이스를 가능한 한 사용하면, GUI또는 J2ME와 같은 영역에서도 재사용 가능합니다.
ㅇ 컨트롤러에서 모델 코드부분을 분리하면 원격 비즈니스 컴포넌트 사용으로 옮겨가는 것이 수월해집니다.
—————————————————————모델, 뷰, 컨트롤러 원칙
ㅇ 모델, 뷰, 컨트롤러는 다음에 기초를 둠
– 관심 영역의 분리
– 느슨한 결합
ㅇ 개별 컴포넌트의 응집력이 높아집니다.
ㅇ 애플리케이션 전체 복잡도는 높아집니다.
ㅇ 수정사항이 애플리케이션의 다른 영역에 최소한의 영향만 줍니다.

프론트 컨트롤러
일반적이며, 반복적인 요청 처리 부분을 하나의 컴포넌트화 하는데 프론트 컨트롤러를 사용하세요 이 패턴을 사용하면 애플리케이션 컨트롤러는 훨씬 응집력이 있으며, 덜 복잡한 모습을 보일것입니다.
—————————————————————프론트 컨트롤러 특징
ㅇ 웹 애플리케이션의 초기 요청 처리 작업을 하나의 컴포넌트로 집중화함
ㅇ 다른 패턴과 프론트 컨트롤러를 함께 사용하면 프리젠테이션 티어 디스패칭 작업을 선언적으로 할수 있으므로 컴포넌트간 결합도를 낮추는 역할을 함
ㅇ 프론트 컨트롤러의 단점은 스트럿츠와 비교해보면 너무 빈약하다는 것입니다. 프론트 컴트롤러 패턴에서 부터 출발하여 제대로 된 애플리케이션을 만들다 보면, 스트럿츠에 이미 구현된 것들을 재작성하고 있다는 것을 알수 있을것입니다.
—————————————————————프론트 컨트롤러 원칙
ㅇ 프론트 컨트롤러는 다음에 기초를 둠 :
– 복잡성을 숨긴다.
– 관심 영역의 분리
– 느슨한 결합
ㅇ 애플리케이션 컨트롤러 컴포넌트 응집성을 높입니다.
ㅇ 애플리케이션 복잡성을 낮춥니다.
ㅇ 기반 구조의 코드 유지보수성을 좋게 합니다.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.