반응형
Singleton 패턴을 적용한 매니저 클래스를 이용하여 모델 1 구조보다 견고하고 확장가능한 웹 어플리케이션을 개발하는 것에 대해 알아본다.
JSP 모델 1 구조의 한계
최근에 자바를 사용하여 웹 어플리케이션을 구축하는 개발자들은 JSP/Servlet/EJB 에 대해서 한두번씩은 경험하고 있을 것이다. 특히, 이제 막 웹 어플리케이션 개발 세계에 발을 들인 사람들은 JSP를 공부하고 있을 것이다. 하지만, 아쉽게도 많은 개발자들이 JSP를 이용하여 웹 어플리케이션을 개발할 때, JSP와 자바의 장점을 살리지 못하고 있는 것 같다. 특히, JSP 페이지에서 모든 필요한 비지니스 로직을 구현하는 경우가 많으며, 증권 사이트와 같은 대형 사이트를 구축할 경우에는 종종 JSP 페이지의 소스 코드가 1000 줄이 넘는 경우도 발생하고 있다. 즉, JSP 페이지에서 표현을 위한 HTML 부분을 제외한 나머지 (비지니스) 로직 부분이 소스 코드의 반절 이상을 차지한다는 것이다. 특히, EJB를 사용하지 않는 경우 그 정도는 더 심하다고 할 수 있다. 실제로 대규모가 아닌 사이트의 경우 대부분 EJB를 사용하지 않으며, 따라서 EJB를 사용하지 않는 중소규모의 웹 어플리케이션의 경우 많은 개발자들이 다음과 같은 구조로 개발하곤 한다.
위 그림은 JSP에서 모든 필요로 하는 비지니스 로직을 구현하는 것을 보여주고 있다. 이러한 형태로 웹 어플리케이션을 개발하는 것의 장점은 쉽다는 점이며, 개발 기간이 상대적으로 짧다는 점이다. 하지만, 이러한 모델1 구조는 다음과 같은 단점을 갖게 된다.
이러한 문제는 이 글에서 설명할 매니저 클래스를 사용함으로써 해결될 수 있다. 여러분은 매니저 클래스를 사용함으로써 모델 1 구조와 모델 2 구조의 중간적인 형태를 구현할 수 있으며, 따라서 모델 1 구조의 단점을 극복하면서 동시에 모델 2 구조의 장점을 취할 수 있게 된다. 매니저 클래스는 Singleton 패턴을 사용하여 구현하며, 먼저 Singleton 패턴에 대해서 알아보기로 하자.
Singleton 패턴
여러 패턴 중에서 Singleton 패턴은 비교적 구현이 간단하며, 정의는 다음과 같다. (이 글에서는 Singleton 패턴이 왜 필요한지에 대한 설명은 하지 않겠으며, Singleton 패턴의 실제 구현에 초점을 맞추도록 하겠다).
이제 좀 더 쉽게 이 말을 설명해보자. 우리는 흔히 특정한 클래스의 인스턴스(또는 객체)를 생성할 때 다음과 같이 new 키워드를 사용한다.
위 코드에서 첫번째 new 연산과 두번째 new 연산은 서로 다른 Date 클래스의 인스턴스를 생성하며, 따라서 date1과 date2는 서로 다른 인스턴스를 참조하게 된다. 즉, Date 클래스의 인스턴스가 여러개 존재할 수 있는 것이다. 반면에 Singleton 패턴을 적용한 클래스의 경우는 new 키워드를 사용하여 인스턴스를 생성하는 일반적인 객체 생성 방법을 사용하지 않는다. Singleton 패턴을 적용한 클래스는 getInstance()라는 메소드를 사용하여 인스턴스를 구한다. 보통 다음과 같은 형태로 Singleton 패턴을 사용하는 클래스의 인스턴스를 구한다.
여기서 SingletonClass 클래스의 static 메소드인 getInstance()는 단 한 개의 인스턴스를 리턴하며, 따라서 sac1과 sac2는 같은 인스턴스를 참조하게 된다.
Singleton 패턴의 구현
Singleton 패턴을 적용한 클래스는 오직 한 개의 인스턴스만을 갖는다고 하였다. 이 말은 아무곳에서나 new 키워드를 통해서 인스턴스를 생성할 수 있으면 안 된다는 것을 의미한다. 따라서, Singleton 패턴을 구현하기 위해서는 먼저 생성자를 private으로 선언해야 한다. Singleton 패턴을 적용한 클래스가 SingletonClass라고 할 경우 전체적인 클래스의 정의는 다음과 같은 형태를 취한다.
위 코드를 보면 static 필드로 instance가 정의되어 있는 것을 알 수 있다. static으로 선언되었기 때문에, instance 필드는 SingletonClass 클래스에 대해서 오직 한 개만 존재하며 따라서 Singleton 패턴의 정의를 만족시킨다. getInstance() 메소드는 단순히 instance 필드를 리턴하면 된다. 이렇게 구현함으로써 SingletonClass 클래스를 사용하는 모든 것들은 오직 한 개의 인스턴스를 공유하게 된다. 여기서 한 가지 짚고 넘어갈 것이 있다면, SingletonClass 클래스가 실제로 사용되는 지의 여부에 상관없이 항상 SingletonClass 클래스의 인스턴스가 생성된다는 점이다. 실제로 인스턴스를 생성할 필요가 있는 시점은 처음으로 getInstance() 메소드가 호출되는 때이며, 따라서 다음과 같이 코드를 변경할 수 있다.
이제 getInstance()가 처음으로 호출되는 순간에 SingletonClass의 인스턴스가 생성된다. (이처럼 처음부터 인스턴스를 생성하지 않고 필요한 순간에 인스턴스를 생성하는 것을 'Lazy Instantiation' 이라고 하며, 시스템 자원을 효율적으로 사용하기 위해서 많이 사용된다). 하지만, 위 코드를 살펴보면 문제점을 발견할 수 있을 것이다. 바로 동기화이다. 동시에 두 개의 쓰레드가 getInstace()를 호출한다면 어떻게 될까? 알맞게 동기화 처리가 되어 있지 않기 때문에, 두 개의 인스턴스가 생성될 수 있다. 이는 Singleton 패턴의 정의에 어긋나는 것이며, 따라서 멀티 쓰레드 환경에서 문제가 발생하지 않도록 동기화 처리를 해 주어야 한다. 동기화 처리를 하도록 변형된 getInstance() 메소드는 다음과 같다.
위 코드에서 if 문을 두번한 것을 알 수 있다. 이 처럼 두 번 체크 하는 것을 'double-check idiom'이라 한다. 이와 관련된 내용은 Doug Lea가 쓴 'Concurrent Programming in Java, Second Edition: Design Principles and Patterns'(Addison Wesley)에 자세한 내용이 있으니 참조하기 바란다. 또한, Lazy Instantiation에 대한 내용은 JavaWorld Tip 65에서 참고할 수 있다.
Singleton 패턴을 이용한 매니저 클래스
여러분이 쇼핑몰을 구축한다고 해보자. 이 웹 어플리케이션은 제품 주문/주문 취소/주문 제품 목록 표시 등의 기능을 제공해야 한다. 여기서 나열한 기능은 모두 "제품 구매"라는 하나의 처리 과정에 속하며, 따라서 하나의 처리 과정에 속하는 기능을 하나의 클래스에서 관리하도록 할 수 있다. 이처럼 특정한 기능들을 제공하고 관리하는 클래스를 매니저 클래스라 할 수 있으며, 보통 클래스 이름에 Manager 라는 단어를 붙이곤 한다. 예를 들어, 회원 관리 기능을 제공하는 클래스를 MemberManager라고 이름지을 수 있다.
웹 어플리케이션은 이처럼 일련의 기능들이 하나의 매니저 클래스로 묶이는 경우가 많다. 예를 들어, 회원 관리/구매 관리/게시판/방명록/배너 광고 관리 등은 각각 별도의 매니저 클래스를 통해서 필요한 기능들을 제공할 수 있을 것이다. 여기서 중요한 점은 매니저 클래스에서 모든 중요한 기능-거의 대부분은 DB 처리일 것이다-을 수행한다는 것이다. 예를 들어, 회원 관리를 생각해보자. 회원 관리에는 회원 추가/회원 탈퇴/회원 정보 변경 등의 기능이 필요하며, MemberManager 클래스가 이러한 기능을 제공한다고 해보자. 이 경우 전체적인 구조는 다음과 같을 것이다.
즉, 회원과 관련된 모든 기능은 MemberManager 클래스를 통해서 이루어지는 것이다. 즉, 매니저 클래스가 모든 기능의 엔트리 포인트(Entry Point; 진입 지점)가 되는 것이다. 이처럼 매니저가 중요한 모든 기능을 제공하는 경우 매니저 클래스의 인스턴스가 두 개 이상 생성되는 것은 문제가 될 수 있으며, 동기화 처리에 있어서 특히 문제가 될 수 있다. 따라서 매니저 클래스는 Singleton 패턴을 적용하여 구현해야 하며, 따라서 대부분의 매니저 클래스는 다음과 같은 형태로 정의된다.
필요에 따라 어떤 기능을 하는 doSomeFunction1()이나 getSomeInfo2()와 같은 메소드의 선언부분에 동기화를 위한 목적으로 synchronized 키워드를 추가할 수 있으며, 또는 메소드 내부의 필요한 곳에서 synchronized() 블럭을 사용하여 동기화를 할 수도 있다. 매니저 클래스는 다음과 같은 형태로 사용하면 된다.
JSP 페이지와 매니저 클래스
이제 마지막으로 JSP 페이지에서 매니저 클래스를 사용하는 것에 대해서 알아보자. JSP 페이지와 매니저 클래스의 관계는 다음 그림과 같다.
위 그림에서 실제 내부 로직은 매니저 클래스에서 담당하며 JSP는 매니저에 데이터를 넘겨주거나(보통 자바빈 컴포넌트를 넘겨준다) 매니저로부터 필요한 데이터를 넘겨받을 것이다. JSP 페이지는 단지 필요한 매니저를 사용하면 될 뿐, 매니저 클래스에서 내부적으로 어떤 자원을 사용하는 지, 내부 로직이 어떻게 되는 지에 대해선 전혀 알 필요가 없다. 또한, 동기화 문제 역시 매니저 클래스 내부에서 처리되므로 JSP는 동기화에 대한 특별한 처리를 할 필요가 없다.
실제로 JSP 페이지에서 매니저를 사용하는 것은 매우 간단하다. 먼저 특정 매니저 클래스의 getInstance()를 호출하여 인스턴스를 구한 후, 필요로 하는 기능을 제공하는 메소드를 호출하면 된다. 예를 들어, 신규 회원 가입을 처리하는 JSP 페이지가 있다고 해 보자. 이 JSP 페이지는 HTML 폼을 통해서 회원의 이름, 사용할 ID, 암호, 주소 등 다양한 정보를 입력받을 것이다. 이때, 신규 회원 가입 JSP 페이지는 다음과 같은 순서로 신규 회원 가입을 처리할 것이다. (여기서, MemberManager 클래스는 회원과 관련된 기능을 제공하는 매니저 클래스이며, MemberBean 클래스는 사용자가 입력한 정보를 저장하는 자바빈 컴포넌트라고 가정한다).
회원의 정보를 변경하는 페이지 역시 다음과 같은 구조를 이룰 것이다.
이 두 JSP가 매우 간단하다는 것을 알 수 있다. 동기화를 비롯한 모든 처리가 매니저를 통해서 이루어지기 때문에 웹 어플리케이션의 전체적인 구조가 견고해진다. 또한, 내부 로직이 변경되거나 MemberBean 클래스가 변경되더라도 단지 MemberManager 클래스만 변경하면 될 뿐, JSP 페이지는 거의 영향을 받지 않는다. 따라서 유지/보수가 JSP에서 비지니스 로직을 직접적으로 구현하는 것에 비해 훨씬 용이하다. 그리고 매니저 클래스를 사용할 경우 JSP에서 모든 걸 구현할 때에 비해 좀 더 손쉽게 모델 2 구조로 확장할 수 있으며, EJB로의 확장 역시 용이하다.
하지만, 아쉽게도 디버깅에 있어서는 아직 별다른 진전을 보이지 못한다. 그저 여러 JSP 페이지가 아닌 하나의 .java 파일을 검사하면 된다는 것에 위안을 삼아야 할 처지이다. 자바 개발자에게 있어서 디버깅은 정말로 골치덩어리인거 같다. 하루라도 빨리 개발자들을 조금이라도 편하게 해줄 자바 디버깅 툴이 나오길 바랄 뿐이다.
결론
Singleton 패턴을 적용한 매니저 클래스는 JSP에서 로직과 표현을 담당하는 모델 1 구조와 로직은 서블릿에서 담당하고 표현은 JSP에서 담당하는 모델 2 구조의 중간 형태를 구현할 수 있도록 해 준다. 매니저 클래스를 사용함으로써 모델 1 구조의 단점을 극복하고 좀 더 견고한 웹 어플리케이션을 개발할 수 있게 되었으며, 차후에 좀 더 손쉽게 웹 어플리케이션을 확장할 수 있게 되었다. 또한 매니저 클래스는 웹 어플리케이션 뿐만 아니라 대부분의 어플리케이션에서 사용할 수 있으므로 여러분의 어플리케이션에서 손쉽게 활용할 수 있을 것이다.
관련링크:
JSP 모델 1 구조의 한계
최근에 자바를 사용하여 웹 어플리케이션을 구축하는 개발자들은 JSP/Servlet/EJB 에 대해서 한두번씩은 경험하고 있을 것이다. 특히, 이제 막 웹 어플리케이션 개발 세계에 발을 들인 사람들은 JSP를 공부하고 있을 것이다. 하지만, 아쉽게도 많은 개발자들이 JSP를 이용하여 웹 어플리케이션을 개발할 때, JSP와 자바의 장점을 살리지 못하고 있는 것 같다. 특히, JSP 페이지에서 모든 필요한 비지니스 로직을 구현하는 경우가 많으며, 증권 사이트와 같은 대형 사이트를 구축할 경우에는 종종 JSP 페이지의 소스 코드가 1000 줄이 넘는 경우도 발생하고 있다. 즉, JSP 페이지에서 표현을 위한 HTML 부분을 제외한 나머지 (비지니스) 로직 부분이 소스 코드의 반절 이상을 차지한다는 것이다. 특히, EJB를 사용하지 않는 경우 그 정도는 더 심하다고 할 수 있다. 실제로 대규모가 아닌 사이트의 경우 대부분 EJB를 사용하지 않으며, 따라서 EJB를 사용하지 않는 중소규모의 웹 어플리케이션의 경우 많은 개발자들이 다음과 같은 구조로 개발하곤 한다.
위 그림은 JSP에서 모든 필요로 하는 비지니스 로직을 구현하는 것을 보여주고 있다. 이러한 형태로 웹 어플리케이션을 개발하는 것의 장점은 쉽다는 점이며, 개발 기간이 상대적으로 짧다는 점이다. 하지만, 이러한 모델1 구조는 다음과 같은 단점을 갖게 된다.
- 동기화 문제: 여러 JSP 페이지에서 동시에 시스템의 동일한 자원에 접근하므로 동기화가 문제가 될 수 있으며, JSP 페이지에서 직접적으로 동기화를 처리할 수 있다고 해도 그리 간단하게 해결되지는 않는다.
- 디버깅의 어려움: 같은 작업 단위(예를 들어, 게시판 글쓰기/글읽기/목록 보기)에 속한 것들을 여러 개의 JSP 페이지에서 나누어 처리하므로 각 페이지 별로 디버깅해야 한다.
- 유지/보수의 어려움: 같은 작업 단위에 속한 JSP 페이지들이 각각 비지니스 로직을 갖고 있기 때문에 내부 로직이 변경될 경우 영향을 받는 모든 JSP 페이지를 손봐야 한다.
이러한 문제는 이 글에서 설명할 매니저 클래스를 사용함으로써 해결될 수 있다. 여러분은 매니저 클래스를 사용함으로써 모델 1 구조와 모델 2 구조의 중간적인 형태를 구현할 수 있으며, 따라서 모델 1 구조의 단점을 극복하면서 동시에 모델 2 구조의 장점을 취할 수 있게 된다. 매니저 클래스는 Singleton 패턴을 사용하여 구현하며, 먼저 Singleton 패턴에 대해서 알아보기로 하자.
Singleton 패턴
여러 패턴 중에서 Singleton 패턴은 비교적 구현이 간단하며, 정의는 다음과 같다. (이 글에서는 Singleton 패턴이 왜 필요한지에 대한 설명은 하지 않겠으며, Singleton 패턴의 실제 구현에 초점을 맞추도록 하겠다).
"한 클래스의 인스턴스가 오직 한 개만 존재한다."
이제 좀 더 쉽게 이 말을 설명해보자. 우리는 흔히 특정한 클래스의 인스턴스(또는 객체)를 생성할 때 다음과 같이 new 키워드를 사용한다.
Date date1 = new Date();
Date date2 = new Date();
Date date2 = new Date();
위 코드에서 첫번째 new 연산과 두번째 new 연산은 서로 다른 Date 클래스의 인스턴스를 생성하며, 따라서 date1과 date2는 서로 다른 인스턴스를 참조하게 된다. 즉, Date 클래스의 인스턴스가 여러개 존재할 수 있는 것이다. 반면에 Singleton 패턴을 적용한 클래스의 경우는 new 키워드를 사용하여 인스턴스를 생성하는 일반적인 객체 생성 방법을 사용하지 않는다. Singleton 패턴을 적용한 클래스는 getInstance()라는 메소드를 사용하여 인스턴스를 구한다. 보통 다음과 같은 형태로 Singleton 패턴을 사용하는 클래스의 인스턴스를 구한다.
SingletonClass sac1 = SingletonClass.getInstance();
SingletonClass sac2 = SingletonClass.getInstance();
SingletonClass sac2 = SingletonClass.getInstance();
여기서 SingletonClass 클래스의 static 메소드인 getInstance()는 단 한 개의 인스턴스를 리턴하며, 따라서 sac1과 sac2는 같은 인스턴스를 참조하게 된다.
Singleton 패턴의 구현
Singleton 패턴을 적용한 클래스는 오직 한 개의 인스턴스만을 갖는다고 하였다. 이 말은 아무곳에서나 new 키워드를 통해서 인스턴스를 생성할 수 있으면 안 된다는 것을 의미한다. 따라서, Singleton 패턴을 구현하기 위해서는 먼저 생성자를 private으로 선언해야 한다. Singleton 패턴을 적용한 클래스가 SingletonClass라고 할 경우 전체적인 클래스의 정의는 다음과 같은 형태를 취한다.
class SingletonClass {
private static SingletonClass instance = new SingletonClass();
public static SingletonClass getInstance() {
return instance;
}
private SingletonClass() {
// 초기화
}
// 기타 다른 메소드의 정의가 온다.
.....
}
private static SingletonClass instance = new SingletonClass();
public static SingletonClass getInstance() {
return instance;
}
private SingletonClass() {
// 초기화
}
// 기타 다른 메소드의 정의가 온다.
.....
}
위 코드를 보면 static 필드로 instance가 정의되어 있는 것을 알 수 있다. static으로 선언되었기 때문에, instance 필드는 SingletonClass 클래스에 대해서 오직 한 개만 존재하며 따라서 Singleton 패턴의 정의를 만족시킨다. getInstance() 메소드는 단순히 instance 필드를 리턴하면 된다. 이렇게 구현함으로써 SingletonClass 클래스를 사용하는 모든 것들은 오직 한 개의 인스턴스를 공유하게 된다. 여기서 한 가지 짚고 넘어갈 것이 있다면, SingletonClass 클래스가 실제로 사용되는 지의 여부에 상관없이 항상 SingletonClass 클래스의 인스턴스가 생성된다는 점이다. 실제로 인스턴스를 생성할 필요가 있는 시점은 처음으로 getInstance() 메소드가 호출되는 때이며, 따라서 다음과 같이 코드를 변경할 수 있다.
class SingletonClass {
private static SingletonClass instance = null;
public static SingletonClass getInstance() {
if (instance == null)
instance = new SingletonClass();
return instance;
}
private SingletonClass() {
// 초기화
}
// 기타 다른 메소드의 정의가 온다.
.....
}
private static SingletonClass instance = null;
public static SingletonClass getInstance() {
if (instance == null)
instance = new SingletonClass();
return instance;
}
private SingletonClass() {
// 초기화
}
// 기타 다른 메소드의 정의가 온다.
.....
}
이제 getInstance()가 처음으로 호출되는 순간에 SingletonClass의 인스턴스가 생성된다. (이처럼 처음부터 인스턴스를 생성하지 않고 필요한 순간에 인스턴스를 생성하는 것을 'Lazy Instantiation' 이라고 하며, 시스템 자원을 효율적으로 사용하기 위해서 많이 사용된다). 하지만, 위 코드를 살펴보면 문제점을 발견할 수 있을 것이다. 바로 동기화이다. 동시에 두 개의 쓰레드가 getInstace()를 호출한다면 어떻게 될까? 알맞게 동기화 처리가 되어 있지 않기 때문에, 두 개의 인스턴스가 생성될 수 있다. 이는 Singleton 패턴의 정의에 어긋나는 것이며, 따라서 멀티 쓰레드 환경에서 문제가 발생하지 않도록 동기화 처리를 해 주어야 한다. 동기화 처리를 하도록 변형된 getInstance() 메소드는 다음과 같다.
public static SingletonClass getInstance() {
if (instance == null)
synchronized(SingletonClass.class) {
if (instance == null)
instance = new SingletonClass();
}
return instance;
}
if (instance == null)
synchronized(SingletonClass.class) {
if (instance == null)
instance = new SingletonClass();
}
return instance;
}
위 코드에서 if 문을 두번한 것을 알 수 있다. 이 처럼 두 번 체크 하는 것을 'double-check idiom'이라 한다. 이와 관련된 내용은 Doug Lea가 쓴 'Concurrent Programming in Java, Second Edition: Design Principles and Patterns'(Addison Wesley)에 자세한 내용이 있으니 참조하기 바란다. 또한, Lazy Instantiation에 대한 내용은 JavaWorld Tip 65에서 참고할 수 있다.
Singleton 패턴을 이용한 매니저 클래스
여러분이 쇼핑몰을 구축한다고 해보자. 이 웹 어플리케이션은 제품 주문/주문 취소/주문 제품 목록 표시 등의 기능을 제공해야 한다. 여기서 나열한 기능은 모두 "제품 구매"라는 하나의 처리 과정에 속하며, 따라서 하나의 처리 과정에 속하는 기능을 하나의 클래스에서 관리하도록 할 수 있다. 이처럼 특정한 기능들을 제공하고 관리하는 클래스를 매니저 클래스라 할 수 있으며, 보통 클래스 이름에 Manager 라는 단어를 붙이곤 한다. 예를 들어, 회원 관리 기능을 제공하는 클래스를 MemberManager라고 이름지을 수 있다.
웹 어플리케이션은 이처럼 일련의 기능들이 하나의 매니저 클래스로 묶이는 경우가 많다. 예를 들어, 회원 관리/구매 관리/게시판/방명록/배너 광고 관리 등은 각각 별도의 매니저 클래스를 통해서 필요한 기능들을 제공할 수 있을 것이다. 여기서 중요한 점은 매니저 클래스에서 모든 중요한 기능-거의 대부분은 DB 처리일 것이다-을 수행한다는 것이다. 예를 들어, 회원 관리를 생각해보자. 회원 관리에는 회원 추가/회원 탈퇴/회원 정보 변경 등의 기능이 필요하며, MemberManager 클래스가 이러한 기능을 제공한다고 해보자. 이 경우 전체적인 구조는 다음과 같을 것이다.
즉, 회원과 관련된 모든 기능은 MemberManager 클래스를 통해서 이루어지는 것이다. 즉, 매니저 클래스가 모든 기능의 엔트리 포인트(Entry Point; 진입 지점)가 되는 것이다. 이처럼 매니저가 중요한 모든 기능을 제공하는 경우 매니저 클래스의 인스턴스가 두 개 이상 생성되는 것은 문제가 될 수 있으며, 동기화 처리에 있어서 특히 문제가 될 수 있다. 따라서 매니저 클래스는 Singleton 패턴을 적용하여 구현해야 하며, 따라서 대부분의 매니저 클래스는 다음과 같은 형태로 정의된다.
public SomeManager extends SuperClass implements SuperInterface {
private static SomeManager instance = null;
public static SomeManager getInstance() { // Singleton 패턴
if (instance == null)
synchronized(syncObj) {
if (instance == null)
instance = new SingletonClass();
}
return instance;
}
private SomeManager() {
// 초기화
}
public void doSomeFunction1(...) {
// 어떤 기능을 수행한다.
}
public AnyBean getSomeInfo2(...) {
// 어떤 정보를 구한다.
return abean;
}
.....
}
private static SomeManager instance = null;
public static SomeManager getInstance() { // Singleton 패턴
if (instance == null)
synchronized(syncObj) {
if (instance == null)
instance = new SingletonClass();
}
return instance;
}
private SomeManager() {
// 초기화
}
public void doSomeFunction1(...) {
// 어떤 기능을 수행한다.
}
public AnyBean getSomeInfo2(...) {
// 어떤 정보를 구한다.
return abean;
}
.....
}
필요에 따라 어떤 기능을 하는 doSomeFunction1()이나 getSomeInfo2()와 같은 메소드의 선언부분에 동기화를 위한 목적으로 synchronized 키워드를 추가할 수 있으며, 또는 메소드 내부의 필요한 곳에서 synchronized() 블럭을 사용하여 동기화를 할 수도 있다. 매니저 클래스는 다음과 같은 형태로 사용하면 된다.
SomeManager sMgr = SomeManager.getInstance();
// 필요한 기능을 하는 메소드 호출
sMgr.doSomeFunction1();
.....
// 필요한 기능을 하는 메소드 호출
sMgr.doSomeFunction1();
.....
JSP 페이지와 매니저 클래스
이제 마지막으로 JSP 페이지에서 매니저 클래스를 사용하는 것에 대해서 알아보자. JSP 페이지와 매니저 클래스의 관계는 다음 그림과 같다.
위 그림에서 실제 내부 로직은 매니저 클래스에서 담당하며 JSP는 매니저에 데이터를 넘겨주거나(보통 자바빈 컴포넌트를 넘겨준다) 매니저로부터 필요한 데이터를 넘겨받을 것이다. JSP 페이지는 단지 필요한 매니저를 사용하면 될 뿐, 매니저 클래스에서 내부적으로 어떤 자원을 사용하는 지, 내부 로직이 어떻게 되는 지에 대해선 전혀 알 필요가 없다. 또한, 동기화 문제 역시 매니저 클래스 내부에서 처리되므로 JSP는 동기화에 대한 특별한 처리를 할 필요가 없다.
실제로 JSP 페이지에서 매니저를 사용하는 것은 매우 간단하다. 먼저 특정 매니저 클래스의 getInstance()를 호출하여 인스턴스를 구한 후, 필요로 하는 기능을 제공하는 메소드를 호출하면 된다. 예를 들어, 신규 회원 가입을 처리하는 JSP 페이지가 있다고 해 보자. 이 JSP 페이지는 HTML 폼을 통해서 회원의 이름, 사용할 ID, 암호, 주소 등 다양한 정보를 입력받을 것이다. 이때, 신규 회원 가입 JSP 페이지는 다음과 같은 순서로 신규 회원 가입을 처리할 것이다. (여기서, MemberManager 클래스는 회원과 관련된 기능을 제공하는 매니저 클래스이며, MemberBean 클래스는 사용자가 입력한 정보를 저장하는 자바빈 컴포넌트라고 가정한다).
- <jsp:useBean>와 <jsp:setProperty> 액션 태그를 사용하여 사용자가 입력한 정보를 자바빈 컴포넌트에 저장한다.
- MemberManager 클래스의 Singleton 인스턴스를 구한다.
- 매니저의 회원 가입 메소드를 호출한다. 이 때, 1에서 생성한 자바빈 컴포넌트를 인자로 넘겨준다.
<%@ page import = "com.mypackage.member.MemberManager" %>
<%@ page errorPage = "error_page.jsp" %>
<%-- 자바빈 컴포넌트를 생성해서 사용자가 입력한 값을 저장한다. --%>
<jsp:useBean id="newData" class="com.mypackage.member.bean.MemberBean">
<jsp:setProperty name="newData" property="*" />
</jsp:useBean>
<% MemberManager mMgr = MemberManager.getInstance();
mMgr.registerNewMember(newData); // 새로운 회원 추가
// 예외가 발생할 경우 에러 페이지인 error_page.jsp로 이동
%>
<!-- 실제 표현 부 -->
<html>
....
</html>
<%@ page errorPage = "error_page.jsp" %>
<%-- 자바빈 컴포넌트를 생성해서 사용자가 입력한 값을 저장한다. --%>
<jsp:useBean id="newData" class="com.mypackage.member.bean.MemberBean">
<jsp:setProperty name="newData" property="*" />
</jsp:useBean>
<% MemberManager mMgr = MemberManager.getInstance();
mMgr.registerNewMember(newData); // 새로운 회원 추가
// 예외가 발생할 경우 에러 페이지인 error_page.jsp로 이동
%>
<!-- 실제 표현 부 -->
<html>
....
</html>
회원의 정보를 변경하는 페이지 역시 다음과 같은 구조를 이룰 것이다.
<%@ page import = "com.mypackage.member.MemberManager" %>
<%@ page errorPage = "error_page.jsp" %>
<%-- 자바빈 컴포넌트를 생성해서 사용자가 입력한 값을 저장한다. --%>
<jsp:useBean id="updateData" class="com.mypackage.member.bean.MemberBean">
<jsp:setProperty name=" updateData" property="*" />
</jsp:useBean>
<% MemberManager mMgr = MemberManager.getInstance();
mMgr.updateMemberInfo(newData); // 새로운 회원 추가
// 예외가 발생할 경우 에러 페이지인 error_page.jsp로 이동
%>
<!-- 실제 표현 부 -->
<html>
....
</html>
<%@ page errorPage = "error_page.jsp" %>
<%-- 자바빈 컴포넌트를 생성해서 사용자가 입력한 값을 저장한다. --%>
<jsp:useBean id="updateData" class="com.mypackage.member.bean.MemberBean">
<jsp:setProperty name=" updateData" property="*" />
</jsp:useBean>
<% MemberManager mMgr = MemberManager.getInstance();
mMgr.updateMemberInfo(newData); // 새로운 회원 추가
// 예외가 발생할 경우 에러 페이지인 error_page.jsp로 이동
%>
<!-- 실제 표현 부 -->
<html>
....
</html>
이 두 JSP가 매우 간단하다는 것을 알 수 있다. 동기화를 비롯한 모든 처리가 매니저를 통해서 이루어지기 때문에 웹 어플리케이션의 전체적인 구조가 견고해진다. 또한, 내부 로직이 변경되거나 MemberBean 클래스가 변경되더라도 단지 MemberManager 클래스만 변경하면 될 뿐, JSP 페이지는 거의 영향을 받지 않는다. 따라서 유지/보수가 JSP에서 비지니스 로직을 직접적으로 구현하는 것에 비해 훨씬 용이하다. 그리고 매니저 클래스를 사용할 경우 JSP에서 모든 걸 구현할 때에 비해 좀 더 손쉽게 모델 2 구조로 확장할 수 있으며, EJB로의 확장 역시 용이하다.
하지만, 아쉽게도 디버깅에 있어서는 아직 별다른 진전을 보이지 못한다. 그저 여러 JSP 페이지가 아닌 하나의 .java 파일을 검사하면 된다는 것에 위안을 삼아야 할 처지이다. 자바 개발자에게 있어서 디버깅은 정말로 골치덩어리인거 같다. 하루라도 빨리 개발자들을 조금이라도 편하게 해줄 자바 디버깅 툴이 나오길 바랄 뿐이다.
결론
Singleton 패턴을 적용한 매니저 클래스는 JSP에서 로직과 표현을 담당하는 모델 1 구조와 로직은 서블릿에서 담당하고 표현은 JSP에서 담당하는 모델 2 구조의 중간 형태를 구현할 수 있도록 해 준다. 매니저 클래스를 사용함으로써 모델 1 구조의 단점을 극복하고 좀 더 견고한 웹 어플리케이션을 개발할 수 있게 되었으며, 차후에 좀 더 손쉽게 웹 어플리케이션을 확장할 수 있게 되었다. 또한 매니저 클래스는 웹 어플리케이션 뿐만 아니라 대부분의 어플리케이션에서 사용할 수 있으므로 여러분의 어플리케이션에서 손쉽게 활용할 수 있을 것이다.
관련링크: