엔터프라이즈 애플리케이션 아키텍처 패턴 2 - 객체&관계형 매핑, 리포지토리, 프런트 컨트롤러

12장 객체-관계형 구조 패턴 : 식별자 필드

---

 관계형 데이터베이스는 행을 다른 행과 구분하기 위해 기본 키라고 하는 키를 사용한다. 그러나 객체 시스템은 내부적으로 올바른 식별자를 보장하므로 인메모리 객체에는 이러한 키가 필요없다(C++의 경우 원시 메모리 위치를 활용함). 데이터베이스에서 데이터를 읽는 것은 간단하지만 데이터를 다시 기록하려면 데이터베이스와 인메모리 객체 시스템을 연결해야 한다.

 식별자 필드(Identity Field)는 기본적으로 놀라울 만큼 단순하다. 관계형 데이터베이스의 기본 키를 객체의 필드에 저장하는 것이 전부다.

 

 식별자 필드의 기본 개념은 아주 간단하지만 상당히 많은 복잡한 사항이 연관돼 있다.

키 선택 : 첫 번째 문제는 데이터베이스에 있는 어떤 종류의 키를 선택하느냐다. 물론 이미 키 구조를 가지고 있는 기존의 데이터베이스를 사용해야 하는 경우에는 선택의 여지가 없을 수 있다. 이 주제에 대해서는 데이터베이스 커뮤니티 내에서도 많은 토론이 이ㅜ러지고 있고 관련 자료도 많다. 객체에 대한 매핑을 위해서는 몇 가지 고려할 사항이 있다.

 첫 번째 고려 사항은 의미 있는 키와 의미 없는 키 중 어떤 것을 사용할 것이냐다. 의미 있는 키(meaningful key)는 사람을 식별할 때 사용하는 주민등록번호와 비슷한 것이다. 의미 없는 키(meaningless key)는 근본적으로 데이터베이스에서 생성한 임의의 숫자이며, 사람이 보기 위한 값은 아니다. 의미 있는 키의 위험성은 이론상으로는 좋은 키지만 실제로는 그렇지 않다는 것이다. 일단 키 용도로 사용 가능하려면 고유해야 하며, 키 역할을 잘 하려면 읽기 전용이어야 한다. 할당된 숫자는 고유하고 읽기 전용이어야 하지만 사람의 실수 때문에 종종 두 요건을 모두 충족하지 못하는 경우가 있다. 예를 들어, 아내의 주민등록번호 대신 본인의 주민등록번호를 입력하면 결과 레코드는 고유하지 않으며, 이 실수를 수정하려고 하면 읽기 전용도 아니다. 데이터베이스에서 당연히 고유성 문제를 감지해야 하지만 문제 감지는 올바른 레코드가 시스템으로 전달된 후에만 가능하므로 실수를 사전에 막지는 못한다. 따라서 의미 있는 키는 신뢰할 수 없다. 소규모 및/또는 아주 안정적인 시스템에서는 의미 있는 키가 가능할 수 있지만 일반적으로는 의미 없는 키를 선택해야 한다.

 두 번째 고려 사항은 단순 키와 복합 키 중 어떤 것을 사용할 것이냐다. 단순 키(simple key)는 데이터베이스 필드를 하나만 사용하지만 복합 키(compound key)는 필드를 두 개 이상 사용한다. 복합 키의 장점은 한 테이블이 다른 테이블의 컨텍스트에서 의미가 있는 경우 사용하기 쉬운 경우가 많다는 것이다. 좋은 예로 주문과 품목이 있는데, 품목의 키에는 주문 번호와 품목의 시퀀스 번호를 결합한 복합 키가 적절하다. 복합 키가 적절한 경우가 많지만 단순 키의 순수한 균일성도 중요한 고려 사항이다. 모든 곳에서 단순 키를 사용한다면 모든 키 조작에 동일한 코드를 사용할 수 있다. 복합 키를 사용하려면 구현 클래스에서 특별한 처리가 필요하다(코드 생성을 이용하면 문제가 되지 않는다). 또한 복합 키는 약간의 의미를 포함하므로 고유성과 함께 특히 불변성 규칙에 주의해야 한다.

 키의 형식도 선택해야 한다. 키를 사용하는 가장 일반적인 연산은 동등 검사이므로 동등 연산이 빠른 형식을 선택하는 것이 좋다. 다음으로 중요한 연산은 다음 키를 얻는 것이다. 따라서 정수(long) 형식을 선택하는 경우가 많다. 문자열도 사용 가능하지만 동등 검사가 약간 느리며 문자열을 증가시키기가 힘들 수 있다. DBA가 무엇을 선호하느냐에 따라 결정될 수도 있다.

 (키에 날짜나 시간을 사용하는 것은 피해야 한다. 이러한 키는 의미가 있을 뿐 아니라 이식성과 일관성을 저해할 수 있다. 특히 날짜는 동기화되지 않아 식별자 문제를 유발하기 쉬운 분수형 초 정밀도로 저장되는 경우가 많으므로 이러한 문제에 취약하다.)

 

13장 객체-관계형 메타데이터 매핑 패턴 : 리포지토리

---

리포지터리 패턴 시퀀스 다이어그램 예시

 복잡한 도메인 모델이 포함된 시스템에서는 도메인 객체를 데이터베이스 접근 코드의 세부 사항으로부터 격리하기 위해 데이터 매퍼가 제공하는 것과 같은 계층을 활용하면 크게 도움된다. 이러한 시스템에서는 쿼리 구성 코드가 집중되는 매핑 계층을 기반으로 다른 추상 계층을 만드는 것을 고려할 수 있다. 도메인 클래스의 수가 많거나 쿼리가 집중적으로 수행되는 경우 이러한 계층의 역할이 더 중요하며, 이러한 계층을 활용해 중복된 쿼리 논리를 최소화할 수 있다.

 리포지토리(Repository)는 도메인과 데이터 매핑 계층 사이를 중재해 인메모리 도메인 객체 컬렉션과 비슷하게 작동한다. 클라이언트 객체는 쿼리 사양을 선언적으로 구성한 다음 이를 리포지토리로 제출해 요건을 충족하는지 확인할 수 있다. 객체의 간단한 컬렉션과 마찬가지로 리포지토리에도 객체를 추가하거나 제거할 수 있으며, 리포지토리에 의해 캡슐화되는 매핑 코드가 적절한 작업을 내부적으로 처리한다. 리포지토리는 데이터 저장소에 저장된 객체의 집합과 이를 대상으로 수행하는 작업을 개념상으로 캡슐화해 지속성 계층에 대한 좀 더 객체지향적 관점을 제공한다. 또한 리포지토리는 도메인과 데이터 매핑 계층 간의 깔끔한 분리와 단방향 의존성의 목표를 달성하도록 지원한다.

 

 리포지토리는 내부적으로는 상당히 복잡하고 정교하지만 겉으로는 간단한 인터페이스다. 먼저, 클라이언트는 쿼리에서 반환받으려는 객체의 특성을 지정하는 조건 객체를 만들어야 한다. 예를 들어, 이름을 기준으로 인물 객체를 검색하려면 criteria.equals(Person.LAST_NAME, "Fowler") 및 criteria.like(Person.FIRST_NAME, "M")과 같은 방식으로 개별 조건을 설정한다. 그런 다음 repository.matching(criteria)를 호출해 성이 Fowler이고 이름이 M으로 시작하는 인물을 나타내는 도메인 객체의 리스트를 반환할 수 있다. 예를 들어, 일치 항목이 하나만 예상되는 경우 컬렉션이 아닌 발견된 객체를 반환하는 soleMatch(criteria)를 사용할 수 있다. 다른 일반적인 메서드로 byObjectId(id)가 있으며, 이 메소드는 soleMatch를 사용해 간단하게 구현할 수 있다.

 리포지토리를 사용하는 코드는 도메인 객체로 이뤄진 간단한 인메모리 컬렉션을 사용하는 코드와 비슷해 보인다. 도메인 객체는 일반적으로 리포지토리 안에 직접 저장되지 않으므로 클라이언트 코드로 노추뢰지 않는다. 리포지토리는 겉으로는 객체의 컬렉션처럼 보일 수 있지만, 코드를 작성할 때는 리포지토리가 수십 만 개의 레코드를 포함하는 상품 테이블과 매핑될 수 있다는 사실을 잘 알고 있어야 한다. 따라서 카탈로그 시스템의 ProductRepository에서 all()을 호출하는 것은 좋지 않은 생각일 수 있다.

 리포지토리는 데이터 매퍼의 특화된 검색기 메서드를 사양 기반 방식의 객체 선택[Evans and Fowler]으로 대체한다. 쿼리 객체를 직접 사용할 때는 클라이언트 코드가 조건 객체(사양 패턴의 간단한 예)를 구성하고, 이를 직접 쿼리 객체에 추가한 다음, 쿼리를 실행해야 한다. 반면 리포지토리를 사용할 때는 클라이언트 코드가 조건을 구성하고 리포지토리에 전달해 조건과 일치하는 객체를 선택하도록 요청하면 된다. 리포지토리를 사용할 때는 클라이언트 코드의 관점에서 쿼리 "실행"이라는 개념이 없으며, 쿼리 사양을 "충족"하는 객체가 선택된다. 약간은 학술적 구분이지만 이러한 차이는 리포지토리의 선언식 객체 상호작용을 잘 나타내며 리포지토리의 강력한 개념을 어느 정도 보여준다.

 내부적으로 리포지토리는 메타데이터 매핑과 쿼리 객체를 결합해 자동으로 조건을 기준으로 SQL 코드를 생성한다. 조건이 자신을 쿼리로 추가할 수 있는지 여부, 쿼리 객체가 조건 객체를 통합하는 방법, 메타데이터 매핑이 상호작용을 제어하는 방법 등은 모두 구현 세부 사항에 속하는 내용이다.

 리포지토리의 객체 원본은 관계형 데이터베이스가 아닐 수도 있지만, 리포지토리는 특화된 전략 객체를 통해 데이터 매핑 컴포넌트를 즉시 대체할 수 있도록 지원하므로 다른 객체 원본을 사용하더라도 전혀 문제가 되지 않는다. 따라서 여러 데이터베이스 스키마나 도메인 객체의 원본을 사용하는 시스템은 물론, 테스트 중에 속도를 높이기 위해 인메모리 객체만 사용하는 경우에도 리포지토리는 많은 도움이 된다.

 리포지토리는 쿼리를 집중적으로 사용하는 코드의 가독성과 명확성을 개선하는 좋은 메커니즘이다. 예를 들어, 쿼리 페이지가 많이 포함된 브라우저 기반 시스템에는 HttpRequest 객체를 깔끔하게 처리해 쿼리 결과를 생성할 수 있는 메커니즘이 필요하다. 요청을 처리하는 처리기 코드는 일반적으로 HttpRequest를 간단하게 또는 자동으로 기준 객체로 변환할 수 있으며, 적절한 리포지토리로 기준을 제출하는 작업은 한두 줄의 코드로 간단하게 처리할 수 있다.

 

 다양한 유형의 도메인 객체와 다수의 쿼리가 사용되는 대규모 시스템에서 리포지토리를 사용하면 모든 쿼리를 처리하는 데 필요한 코드의 양을 줄일 수 있다. 리포지토리는 쿼리를 순수한 객체지향 방식으로 수행할 수 있게 캡슐화하는 사양 패턴(여기에 나오는 조건 객체의 형태로)을 촉진한다. 즉, 리포지토리를 사용하면 특정한 사례에 맞게 쿼리 객체를 설정하는 코드를 모두 제거할 수 있다. 또한 클라이언트는 SQL을 직접 다루지 않고 순수한 객체의 관점에서 코드를 작성할 수 있다.

 여러 데이터 원본을 사용하는 상황에서는 리포지토리가 확실한 역할을 할 수 있다. 가령 단위 테스트 집합을 실행할 때 성능을 위해 완전히 메모리 안에서 실행할 떄와 같이 간단한 인메모리 데이터 저장소를 사용하려는 경우가 있다. 이렇게 하면 데이터베이스에 접근하지 않으므로 오래 걸리는 여러 테스트를 훨씬 빨리 실행할 수 있다. 또한 단위 테스트에 사용할 환경을 준비하는 과정이 훨씬 간소해진다. 데이터베이스에 테스트 데이터를 저장하고 테스트가 끝나면 삭제하는 것보다 여러 도메인 객체를 구성하고 컬렉션에 넣는 것이 훨씬 간단하다.

 또한 다양한 용도로 활용할 수 있다. 애플리케이션이 정상적으로 실행될 때 특정한 유형의 도메인 객체는 항상 메모리에 있어야 한다. 이러한 객체의 예로 읽기 전용 도메인 객체(사용자가 변경할 수 없는 객체)가 있다. 이러한 객체는 일단 메모리로 가져온 후 상태를 유지하며 다시 쿼리하지 않아야 한다. 이 때 리포지토리 패턴에 대한 간단한 확장을 통해 상황에 맞는 다양한 전략을 적용할 수 있다.

 다른 예로 데이터 피드(data feed)를 도메인 객체의 원본으로 사용하는 경우가 있다. 예를 들어, 인터넷을 통해 전송되는 XML 스트림을 SOAP 등을 통해 원본으로 사용할 수 있다. 이 경우 피드를 읽고 XML을 바탕으로 도메인 객체를 생성하는 XMLFeedRepositoryStrategy를 구현할 수 있다.

 

예제: 인물의 의존자 검색

클라이언트 객체의 관점에서 리포지토리를 사용하는 방법은 간단하다. 인물 객체는 데이터베이스에서 해당하는 의존자를 가져오기 위해 비교에 사용할 검색 조건을 나타내는 조건 객체를 만들고 적절한 리포지토리로 전달한다.

public class Person {
    public List dependents() {
        Repository repository = Registry.personRepository();
        Criteria criteria = new Criteria();
        criteria.equal(Person.BENEFACTOR, this);
        return repository.matching(criteria);
    }
}

일반적인 쿼리는 리포지토리의 특수한 하위 클래스를 통해 수행할 수 있다. 리포지토리의 PersonRepository 하위 클래스를 만들고 검색 조건을 생성하는 기능을 리포지토리 자체로 옮길 수 있다.

public class PersonRepository extends Repository {
    public List dependentsOf(Person person) {
        Criteria criteria = new Criteria();
        criteria.equal(Person.BENEFACTOR, this);
        return matching(criteria);
    }
}

이제 인물 객체는 해당 리포지토리에서 곧바로 dependents() 메서드를 호출할 수 있다.

public class Person {
    public List dependents() {
        return Registry.personRepository().dependentsOf(this);
    }
}

 

예제: 리포지토리 전략의 교체

리포지토리의 인터페이스는 도메인 계층이 데이터 원본을 인식하지 않고도 작업할 수 있게 해주므로 클라이언트에서 호출하는 코드를 변경하지 않고도 리포지토리 내부의 쿼리 코드 구현을 리팩터링할 수 있다. 실제로 도메인 코드는 도메인 객체의 원본이나 대상에 신경 쓸 필요가 없다. 인메모리 저장소의 경우 matching() 메서드를 수정해 조건을 충족하는 도메인 객체의 컬렉션에서 선택하게 하면 된다. 다만 여기서 원하는 것은 데이터 저장소를 영구적으로 변경하는 것이 아니라 필요에 따라 데이터 저장소를 전환할 수 있게 하는 것이다. 이를 위해서는 matching() 메서드의 구현을 변경해 쿼리를 수행하는 전략 객체로 위임하게 해야 한다. 이러한 방식의 장점은 여러 전략을 활용할 수 있고 필요에 따라 원하는 전략을 설정할 수 있다는 점이다. 이 예제의 경우 데이터베이스를 쿼리하는 RelationalStrategy와 인메모리 도메인 객체의 컬렉션을 쿼리하는 InMemoryStrategy라는 두 가지 구현을 만들면 된다. 각 전략은 matching() 메서드를 노출하는 RepositoryStrategy 인터페이스를 구현하므로 리포지토리 클래스의 다음과 같은 구현을 사용할 수 있다.

public class Repository {
    private RepositoryStrategy strategy;

    protected List matching(Criteria criteria) {
        return strategy.matching(aCriteria);
    }
}

public class RelationalStrategy implements RepositoryStrategy {
    protected List matching(Criteria criteria) {
        Query query = new Query(myDomainObjectClass());
        query.addCriteria(criteria);
        return query.execute(unitOfWork());
    }
}

public class InMemoryStrategy implements RepositoryStrategy {
    private Set domainObjects;

    protected List matching(Criteria criteria) {
        List results = new ArrayList<>();
        Iterator it = domainObjects.iterator();
        while (it.hasNext()) {
            DomainObject each = (DomainObject) it.next();
            if (criteria.isSatisfiedBy(each))
                results.add(each);
        }
        return results;
    }
}

 

14장 웹 프레젠테이션 패턴 : 프런트 컨트롤러

---

웹 사이트의 모든 요청을 처리하는 컨트롤러

프런트 컨트롤러 패턴 다이어그램

 복잡한 웹 사이트에서 요청을 처리할 때는 비슷한 작업을 많이 해야 한다. 이렇게 웹 사이트에서 자주 수행하는 공통적인 작업에는 보안, 국제화, 특정 사용자에게 특정한 뷰 제공 등이 있다. 입력 컨트롤러 동작이 여러 객체에 흩어져 있는 경우 이러한 동작이 많이 중복될 수 있다. 또한 런타임에 동작을 바꾸기도 어렵다.

 프런트 컨트롤러(Front Controller)는 모든 요청을 단일 처리기 객체로 집중하는 방법으로 요청을 통합 처리한다. 이 객체는 공통적인 동작을 수행하고 데코레이터(decorator)를 사용해 런타임에 수정할 수 있다. 처리기는 요청을 명령 객체로 전달해 특정한 동작을 수행하게 한다.

 

 프런트 컨트롤러는 웹 사이트의 모든 호출을 처리하며 일반적으로 웹 처리기와 명령 계층의 두 부분으로 구성된다. 웹 처리기는 실제로 웹 서버로부터 POST나 GET 요청을 받는 객체다. 웹 처리기는 실행할 작업을 결정하는 데 필요한 정보를 URL과 요청에서 알아낸 다음 이 작업을 처리하도록 명령에 위임한다.

프런트 컨트롤러의 동작 방식

 웹 처리기는 응답을 생성하지 않으므로 거의 항상 서버 페이지가 아닌 클래스로 구현된다. 명령도 서버 페이지가 아닌 클래스이며, HTTP 정보를 전달받는 경우가 많지만 웹 환경에 대한 정보는 전혀 필요로 하지 않는다. 웹 처리기는 실행할 명령을 결정하는 것 외의 다른 작업은 하지 않는 일반적으로 아주 간단한 프로그램이다.

 웹 처리기는 처리할 명령을 정적으로 또는 동적으로 결정할 수 있다. 정적으로 결정할 때는 URL을 구문 분석하고 조건부 논리를 사용한다. 동적으로 셜정할 때는 일반적으로 URL에서 표준에 해당하는 부분을 가져오고 동적 인스턴스화를 통해 명령 클래스를 생성한다.

 정적 방식을 사용하는 경우 논리가 명시적이고, 컴파일 타임에 오류 검사가 가능하며, URL 형식을 유연하게 선택할 수 있다는 것이 장점이다. 동적 방식을 사용하는 경우 웹 처리기를 변경하지 않고 새 명령을 추가할 수 있다.

 동적 호출을 사용할 때는 명령 클래스의 이름을 URL에 넣거나 URL을 명령 클래스 이름과 연결하는 프로퍼티 파일을 사용할 수 있다. 이 경우 프로퍼티 파일도 편집해야 하지만 클래스 이름을 변경할 때 여러 웹 페이지를 검색할 필요 없이 손쉽게 변경할 수 있다.

 인터셉트 필터(intercepting filter)는 [Alur et al.]에 소개된 패턴으로서 프런트 컨트롤러와 함께 사용하면 아주 유용하다. 인터셉트 필터를 사용하면 프런트 컨트롤러의 처리기를 래핑해 인증, 로깅, 로캘(locale) 식별 등을 처리하기 위한 필터 체인(또는 필터의 파이프라인)을 만들 수 있다. 필터를 이용하면 구성 시 사용할 필터를 동적으로 설정할 수 있다.

 이밖에도 롭 미가 알려준 방법으로 보조 웹 처리기와 디스패처로 분리된 2단계 웹 처리기를 사용하는 흥미로운 프런트 컨트롤러의 변형이 있다. 보조 웹 처리기는 HTTP 매개변수에서 기본 데이터를 가져와 디스패처로 전달함으로써 디스패처가 웹 서버 프레임워크에 대해 완전히 독립적으로 작동하게 한다. 이 구성을 사용하면 웹 서버에서 실행하지 않아도 디스패처를 직접 구동할 수 있기 때문에 테스트가 한결 수월해진다.

 처리기와 명령은 모두 컨트롤러의 일부이므로 명령은 당연히 해당하는 응답에 사용할 뷰를 선택할 수 있다. 처리기의 유일한 역할은 실행할 명령을 선택하는 것이다. 명령을 선택한 후에는 해당 요청을 처리하는 다른 역할은 수행하지 않는다.

 

 프런트 컨트롤러는 대응되는 패턴인 페이지 컨트롤러보다 분명히 복잡한 설계이므로 이를 사용하는 장점이 있어야 한다.

 프런트 컨트롤러는 웹 서버에 하나만 구성하면 되며, 웹 처리기가 나머지 디스패치 작업을 처리한다. 즉, 웹 서버의 구성이 간소화되는 장점이 있다. 동적 명령의 경우에는 다른 사항을 변경하지 않고도 새로운 명령을 추가할 수 있다. 또한 웹 서버별로 처리기를 등록하는 방법을 통해 간단하게 이식할 수 있다.

 각 요청에 대해 명령 객체를 새로 생성하므로 명령 클래스를 스레드로부터 안전하게 만들 필요는 없다. 이러한 방식으로 다중 스레드 프로그래밍의 골치 아픈 문제로부터 벗어날 수 있다. 다만 모델 객체와 같은 다른 객체는 공유하지 않아야 한다.

 프런트 컨트롤러에 대해 가장 자주 언급되는 장점 중 하나는 페이지 컨트롤러에서 중복 코드를 분리할 수 있다는 점이다. 그러나 중복 코드를 분리하는 일은 상위 클래스 페이지 컨트롤러를 사용해도 어느 정도 가능하다.

 컨트롤러가 단 하나이므로 [Gang of Four]에서 소개하는 데코레이터를 사용해 런타임에 쉽게 컨트롤러의 동작을 향상시킬 수 있다. 데코레이터는 인증, 문자 임코딩, 국제화 등의 작업에도 활용할 수 있으며, 구성 파일을 통해 이러한 데코레이터를 추가하거나 심지어 서버가 실행 중일 때도 추가할 수 있다([Alur et al.]에서는 인터셉트 필터라는 이름으로 이 방식을 자세히 소개한다)

 

예제: 간단한 디스플레이

다음은 음악가에 대한 정보를 표시하는 창의적이고 혁신적인 작업을 하는 프런트 컨트롤러를 사용하는 예다. 이 예에서는 http://localhost:8080/isa/music?name=barelyWorks&command=Artist 형식의 URL을 사용한다. command 매개변수는 웹 처리기에 사용할 명령을 알려준다.

프런트 컨트롤러를 구현하는 클래스

먼저 서블릿으로 구현한 처리기에 대해 알아본다.

public class FrontServlet {
    
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
        FrontCommand command = getCommand(request);
        command.init(getServletContext(), request, response);
        command.process();
    }
    
    private FrontCommand getCommand(HttpServletRequest request) {
        try {
            return (FrontCommand) getCommandClass(request).newInstance();
        } catch (Exception e) {
            throw new ApplicationException(e);
        }
    }
    
    private Class getCommandClass(HttpServletRequest request) {
        Class result;
        final String commandClassName = "frontController." + (String) request.getParameter("command") + "Command";
        try {
            result = Class.forName(commandClassName);
        } catch (ClassNotFoundException e) {
            result = UnknownCommand.class;
        }
        return result;
    }
}

논리는 간단하다. 처리기는 먼저 명령 이름과 "Command"를 결합한 이름의 클래스를 인스턴스화하고 새로 생성한 명령을 HTTP에서 얻은 필요한 정보를 기준으로 초기화한다. 이 예제에서는 간단한 필수 정보만 전달했지만 실제 사례에서는 HTTP 세션과 같은 부가 정보를 전달해야 한다. 명령을 찾지 못한 경우 특수 사례 패턴을 사용해 알 수 없는 명령을 반환한다. 이처럼 특수 사례를 사용해 오류 검사의 필요성을 많이 줄일 수 있다.

명령은 데이터와 동작을 상당히 많이 공유하며, 웹 서버에서 받은 정보를 사용해 초기화해야 한다.

public class FrontCommand {

    protected ServletContext context;
    protected HttpServletRequest request;
    protected HttpServletResponse response;
    
    abstract public void process() throws ServletException, IOException;
    
    protected void forward(String target) throws ServletException, IOException {
        RequestDispatcher dispatcher = context.getRequestDispatcher(target);
        dispatcher.forward(request, response);
    }

    public void init(ServletContext context, HttpServletRequest request, HttpServletResponse response) {
        this.context = context;
        this.request = request;
        this.response = response;
    }
}

전달 메서드와 같은 공통적인 동작을 제공할 수 있고 실제 명령이 재정의할 추상 처리 명령을 정의한다.

이 예에서 명령 객체는 아주 간단하다. 이 명령 객체가 구현하는 처리 메서드는 모델 객체의 적절한 동작을 호출하고, 뷰에 필요한 정보를 요청에 추가한 다음, 템플릿 뷰로 전달한다.

public class ArtistCommand {

    public void process() throws ServletException, IOException {
        Artist artist = Artist.findNamed(request.getParameter("name"));
        request.setAttribute("helper", new ArtistHelper(artist));
        forward("/artist.jsp");
    }
}

public class UnknownCommand {

    public void process() throws ServletException, IOException {
        forward("/unknown.jsp");
    }
}