Spring 프레임워크 워크북pds13.egloos.com/pds/200901/14/88/a0105788_496df5c348c8f.pdf ·...

One Step Ahead

Spring FrameworkSpring Framework스프링 프레임워크

김상일

[email protected]

2Spring 프레임워크 워크북

- One Step Ahead -

Copyright ⓒ NEXTREE SOFT CO., LTD., 2007, All Rights Reserved.

11장장.. Spring Spring 탄생탄생 배경배경

22장장.. Spring Spring IoCIoC

33장장.. Spring AOPSpring AOP

44장장.. SpringSpring 트랜잭션트랜잭션

55장장.. Spring MVC ISpring MVC I

66장장.. Spring MVC IISpring MVC II

77장장.. SpringSpring과과 EJBEJB

88장장.. Struts, Spring, HibernateStruts, Spring, Hibernate

ContentsContents

Spring Spring 탄생탄생 배경배경


- One Step Ahead -


1. 1. 개요개요 (1)(1)자바가 지속적으로 발전하면서 애플릿보다 더 큰 관심의 대상이 되고 있는 분야는 서블릿, JSP, EJB로 대표되고 있는 J2EE 환경이다.특히 EJB는 지금까지 분산 환경을 지원하기 위하여 필요로 했던 작업을 단순화시키면서 미들웨어 역할을 하는 애플리케이션 개발을 가능하게 하였다.EJB 기반으로 애플리케이션을 개발하면서 다음과 같은 문제점들이 나타나기시작했다.

첫째, EJB를 만들기 위하여 실질적인 구현 클래스 이외에 3개 이상의 클래스를추가적으로 생성해야 하며, JNDI를 통하여 EJB를 관리하기 위한 설정 파일 또한 추가해야 한다.둘째, 구현된 EJB를 테스트하기 위해서는 반드시 EJB 컨테이너에 배포한 다음에 테스트가 가능하다.

그러므로 개발생산성이 급격하게 저하되는 결과를 초래하게 되었다.

셋째, 분산 환경을 지원하기 위하여 클라이언트와 서버 사이에서 이루어지는 직렬화(Serialization)는 EJB 기반 애플리케이션의 실행 속도 저하라는 결과를초래하게 되었다.

이 같은 단점을 보완하기 위하여 웹 애플리케이션 서버(WAS)를 개발하는 대형 벤더들은 EJB 표준을 어기면서 자신들만의 실행 속도 향상 방법을 추가하게 되었다.이와 같이 새로운 기능들이 각 벤더들마다 추가되면서 EJB 기반으로 개발된 애플리케이션들 간의 이식성이 극도로 저하되었다.


- One Step Ahead -


1. 1. 개요개요 (2)(2)Spring 프레임워크는 Lightweight 컨테이너의 선두주자라고 할 수 있으며, EJB가 지원하고 있는 모든 기능들을 포함하고 있다.

Spring 프레임워크에 관심을 가지는 가장 큰 이유

EJB의 단점을 극복

J2EE 기술이 발전하면서 점점 더 복잡해지고 있는 스펙들을 개발자들이 사용하기 쉽도록 지원


- One Step Ahead -


2. 2. 공통공통 모듈모듈 개발개발 (1)(1)1. 기본 아키텍처 (1)

최근 대부분의 중, 대규모 웹 애플리케이션은 효율적으로 개발 및 유지보수하기위하여 [그림]처럼 계층화(Layering)하여 개발하는 것이 일반적이다.

UI 계층(UI Layer), 비즈니스 계층(Business Layer), 퍼시스턴스 계층(Persistence Layer), 도메인 모델 계층(Domain Model Layer)

애플리케이션 개발의 기본 아키텍처

UI 계층 비즈니스 계층 퍼시스턴스 계층Service Locator DAO 클래스

도메인 모델 클래스


- One Step Ahead -



UI 계층

사용자에 대한 요청 및 응답 처리

상위 계층(비즈니스 계층, 퍼시스턴스 계층)에서 발생하는 Exception, Error에 대한 처리

최종 UI에서 표현해야 할 도메인 모델을 엮는 기능

최종 UI에서 입력한 데이터에 대한 유효성 검증(Validation) 기능

비즈니스 로직과 최종 UI 사이를 분리하기 위한 컨트롤러 기능

비즈니스 계층

애플리케이션 비즈니스 로직 처리와 비즈니스와 관련된 도메인 모델의 적합성 검증

트랜잭션(Transaction) 처리

UI 계층과 퍼시스턴스 계층 사이를 연결하는 역할로서 두 계층이 직접적으로 통신하지 않게 하여애플리케이션의 유연성을 증가시킨다.

비즈니스 계층에 있는 객체들 간의 관계를 관리한다.

다른 계층들과 통신하기 위한 인터페이스를 제공한다.

퍼시스턴스 계층

영구 데이터를 빼내어 객체화시킨다.

영구 저장소(ex, 관계형 데이터베이스)에 데이터를 저장, 수정, 삭제한다.

도메인 모델 계층

관계형 데이터베이스의 엔티티와 비슷한 개념

실제 비즈니스 객체를 의미


- One Step Ahead -



네 가지 계층은 독립적으로 분리할 수 있도록 구현해야 한다.

각 계층 사이에서는 도메인 모델을 제외하고 인터페이스(Interface)를 이용하여 통신하는 것이 일반적이다.

도메인 모델은 UI 계층, 비즈니스 계층, 퍼시스턴스 계층 전체에 걸쳐 사용하게된다.


- One Step Ahead -


3. Non EJB 3. Non EJB 아키텍처아키텍처 (1)(1)1. Non EJB 아키텍처 (1)

Non EJB 아키텍처는 EJB를 사용하지 않는 애플리케이션의 모든 아키텍처를통틀어서 일컫는다.

EJB를 사용하지 않을 경우 명확한 아키텍처 없이 프로젝트의 성격에 따라 다양한 방식으로 아키텍처를 설계하는 경우가 많다.

일반적으로 EJB가 등장하기 전에 많은 개발자들이 서블릿 컨테이너 기반으로개발을 진행했던 개발 방식

Non EJB 아키텍처의 경우 프로젝트 개발자에 따라 다양한 형태로 개발하는 것이 가능하기 때문에 하나의 형태로 정형화하는 것은 의미가 없다.

Non EJB 개발 방식의 프로젝트들도 EJB 아키텍처의 영향을 받아서 정형화하여 개발하는 경우가 많아진 것이 사실이지만 아직까지 명확한 계층의 분리가 이루어지지 않은 경우가 대부분이다.


- One Step Ahead -


3. Non EJB 3. Non EJB 아키텍처아키텍처 (2)(2)1. Non EJB 아키텍처 (2)

서블릿 컨테이너 J2EEServer

JSP, Servlet, UI 계층 클래스

비즈니스 인터페이스

비즈니스 구현

DBMSLegacySystem

UI 계층JSP/Servlet,MVC(Struts, Webwork)

Middle Tier(비즈니스 계층,퍼시스턴스 계층)

EIS Tier

퍼시스턴스 계층JDBC API


- One Step Ahead -


3. Non EJB 3. Non EJB 아키텍처아키텍처 (3)(3)2. Non EJB 아키텍처의 장단점

장점추가적인 교육 없이도 초보 개발자들이 쉽게 이해하고 개발하는 것이 가능하다.

초기 개발 속도가 빠르므로 단기적으로 가시적인 성과를 낼 수 있다.

굳이 값비싼 EJB 컨테이너가 아닌 서블릿 컨테이너만으로 운영하는 것이 가능하다.

EJB 컨테이너보다 서블릿 컨테이너의 이식성(Portability)이 훨씬 좋다.따라서 이 개발 방식을 이용할 경우 추후에 컨테이너가 바뀌더라도 손쉽게 대응할 수 있다.

개발주기가 EJB보다 짧기 때문에 개발생산성의 향상을 가져올 수 있다.EJB의 경우에는 애플리케이션이 변경될 경우 개발, 빌드, 배포, 테스트 과정을 거쳐야 함

이 개발 방식은 개발, 테스트 과정을 통하여 개발하는 것이 가능


- One Step Ahead -


3. Non EJB 3. Non EJB 아키텍처아키텍처 (4)(4)2. Non EJB 아키텍처의 장단점

단점초기 개발 속도가 빠르지만 프로젝트가 진행되면서 추가 요청사항이나 변경사항이발생할 경우 대응속도가 느려 프로젝트 후반으로 갈수록 개발 속도가 느려지게 된다.

명확한 계층을 분리 하기가 어렵다.계층 분리가 명확하지 않기 때문에 중복되는 코드가 많이 발생할 확률이 높다.

이로 인해 유지보수 비용이 높다.

사내에 일관된 개발방식을 가지기 어렵다.

분산 환경을 지원할 수 없다.외부시스템과 인터페이스하기 위하여 분산 환경 지원이 필요할 경우 지원하기 힘들다.

비즈니스 로직을 구현하고 있는 비즈니스 객체의 생명주기를 프로그램에서 직접 관리해야 한다.

서블릿과 EJB의 경우 빈의 생명주기를 컨테이너에서 관리하는 것이 가능하다.

그러나 POJO에 대한 생명주기는 프로그램에서 개발자들이 직접 관리할 수 밖에 없다.

EJB가 지원하고 있는 선언적인 트랜잭션(Transaction)과 같은 기능을 사용할 수없다.

애플리케이션을 개발하면서 상당히 많은 시간을 투자해야 하는 부분이 트랜잭션 처리이다.

그러나 Non EJB 아키텍처에서는 프로그램에서 직접 작성하여 트랜잭션을 처리할 수밖에없다.


- One Step Ahead -


4. EJB 4. EJB 아키텍처아키텍처 (1)(1)EJB가 등장하면서 분산 환경에 대한 지원이 과거보다 많이 쉬워짐

UI 계층과 비즈니스 계층을 물리적으로 분리함으로써 애플리케이션 개발에있어서 계층화가 가능

1. EJB 아키텍처 (1)EJB는 EJB 컨테이너 하에서 관리

EJB 컨테이너분산 환경, 트랜잭션 관리, Security 등의 기능 지원

UI 계층JSP, Servlet, MVC(Struts, Webwork)EJB를 직접적으로 호출하지 않고 EJB의 프록시 역할을 하는 Business Delegate를 두어서 분산 환경 하에 있는 EJB를 호출하도록 구현

Business Delegate 역할UI 계층으로 하여금 비즈니스 계층이 분산 환경 하에서 구현되어 있는지를 모르는 상태에서사용하는 것이 가능하도록 함

비즈니스 계층EJB의 Remote 인터페이스나 Local 인터페이스를 가지는 무상태 세션빈이 담당

퍼시스턴스 계층엔티티 빈

EJB가 처음 등장했을 때 많은 프로젝트에서 엔티티빈을 이용했지만 실행 속도의 문제 때문에 최근에는 엔티티빈을 사용하지 않는 것이 일반적이다.


- One Step Ahead -


4. EJB 4. EJB 아키텍처아키텍처 (2)(2)1. EJB 아키텍처 (2)

서블릿 컨테이너 J2EEServer

JSP, Servlet, UI 계층 클래스


비즈니스 Delegate

DBMSLegacySystem

UI 계층JSP/Servlet,MVC(Struts, Webwork)

Middle Tier(비즈니스 계층,퍼시스턴스 계층)

EIS Tier

RMI

J2EEServer(동일또는분리된JVM)

EJB 컨테이너

Session EJB

Entity EJB(옵션)

(Remote, Non-Web 클라이언트)


- One Step Ahead -


4. EJB 4. EJB 아키텍처아키텍처 (3)(3)2. EJB 아키텍처의 장단점

장점정형화된 비즈니스 계층을 제공한다.

EJB는 비즈니스 계층에 대하여 논리적인 분리 뿐만 아니라 물리적인 분리까지 가능하도록지원하고 있다.

선언적인 트랜잭션 관리와 같이 Non EJB 아키텍처에서 지원하기 힘들었던 기능을EJB 컨테이너가 제공한다.

EJB는 다양한 클라이언트에 대한 지원이 가능하다.

분산 기능을 지원하는 것이 가능하다.

비즈니스 객체를 여러 서버에 분산시키는 것이 가능하다.


- One Step Ahead -


4. EJB 4. EJB 아키텍처아키텍처 (4)(4)2. EJB 아키텍처의 장단점

단점분산 환경을 지원하기 위하여 객체를 직렬화하는 과정 때문에 실행 속도의 저하가 발생한다.

개발 사이클이 소스 수정, 빌드, 배포, 테스트와 같이 복잡한 과정을 거치기 때문에 개발생산성이 저하되는 결과를 가져온다.

EJB는 EJB 컨테이너에 종속적이기 때문에 개발한 후 EJB 컨테이너에 배포한 다음에 테스트를 진행해야 한다.

이는 테스트를 어렵게 만들며, 테스트의 어려움으로 인해 제품의 질이 저하되는 결과를 초래한다.

EJB의 실행 속도 문제를 해결하기 위한 방법

EJB를 위한 변형된 패턴들이 나타나면서 객체 지향적으로 개발하는 데 제약사항이 된다.

EJB 자체 스펙이 가지고 있는 실행 속도가 떨어진다는 문제로 인해 EJB 컨테이너를만드는 대형 벤더들 나름대로 자신들만의 기능들을 추가함으로써 EJB 컨테이너 사이의 이식성(Portability)이 떨어진다.


- One Step Ahead -


5. Lightweight 5. Lightweight 아키텍처아키텍처 (1)(1)EJB가 가지고 있는 한계점을 극복하기 위해서는 EJB와 같이 EJB 컨테이너에 종속적이지 않으면서 EJB 컨테이너가 가지고 있는 기능들을 지원할 수 있어야 한다.

Non EJB 아키텍처와 EJB 아키텍처가 가지고 있는 문제점을 해결하고 장점들을 지원하기 위하여 새롭게 등장한 아키텍처가 Lightweight 아키텍처이다.

1. Lightweight 컨테이너 아키텍처 (1)가벼우면서도 컨테이너 기능을 가지고 있는 아키텍처라는 의미

Lightweight라는 용어를 사용한 이유

EJB 컨테이너와 비교하여 가벼운 컨테이너라는 것

컨테이너(Container)가 가지는 의미

EJB 컨테이너가 지원하는 트랜잭션 처리, Security, 빈의 생명주기관리와 같은 컨테이너를 통해서 지원할 수 있는 기능들을 지원하는 것이 가능하다는 것


- One Step Ahead -


5. Lightweight 5. Lightweight 아키텍처아키텍처 (2)(2)1. Lightweight 컨테이너 아키텍처 (2)

서블릿 컨테이너J2EEServer

MVC 프레임워크


선언적인 AOP서비스를 가지는POJO 구현체

RDBMS

UI 계층JSP/Servlet,MVC 프레임워크

Middle Tier

EIS Tier

(Single JVM)

OR Mapping 계층

비즈니스 계층(POJO 비즈니스 객체)퍼시스턴스 계층(OR Mapping 프레임워크/JDBC)


- One Step Ahead -



POJO의 생명주기를 관리하고 POJO에 부가적인 기능을 지원하기 위한 POJO 컨테이너가 존재

POJO(Plain Old Java Object)는 지금까지 일반적으로 자바빈(JavaBean)이라고 불러왔던 클래스들을 일컫는다.

서블릿, EJB와 같이 인터페이스에 종속되어 특정 컨테이너 내부에서만 사용할 수 있는 클래스를 제외한 모든 클래스를 POJO라고 말할 수 있다.

컨테이너에 배포하지 않은 상태에서도 테스트가 가능함으로써 개발생산성의 향상을 가져올 수 있다.

각 계층 사이의 의존관계를 줄이기 위하여 Factory 클래스와 Singleton 패턴을사용하지 않아도 같은 효과를 얻을 수 있다.

각 계층 사이에 인터페이스를 기반으로 통신하는 것이 Non EJB 아키텍처와EJB 아키텍처보다 쉬워진다.

인터페이스를 기반으로 애플리케이션을 개발할 경우 테스트의 용이성이 향상된다.


- One Step Ahead -



Spring 프레임워크

POJO에 대한 컨테이너 기능을 지원하는 대표적인 프레임워크

POJO에 대한 컨테이너적인 역할을 할 뿐만 아니라 각 계층의 의존관계를 유기적으로 연결하고 관리하는 기능을 지원한다.

컨테이너를 이용하여 Non EJB 아키텍처가 가지고 있는 장점과 EJB 아키텍처가 가지고 있는 장점을 모두 수용하는 것이 가능하게 되었다.

Properties 파일이나 XML 파일을 이용하여 POJO 빈에 대한 정보를 관리한다.

웹 애플리케이션을 개발할 경우 web.xml에 설정된 정보를 바탕으로 웹 애플리케이션이 시작할 때 설정 파일에 담겨 있는 정보를 바탕으로 모든 POJO 빈에 대한 생성과 초기화 작업을 한다.

이렇게 생성된 POJO 빈은 Spring 프레임워크 WebApplicationContext에 의해서 관리되며, 이 WebApplicationContext는 웹 애플리케이션과 생명주기를 같이하고 있는 ServletContext에 저장되어 관리된다.

애플리케이션을 개발할 때 각 계층 사이를 추가적인 클래스 없이 느슨하게 결합하는것이 가능하다.

프레임워크 내부에서 POJO 빈을 관리함으로써 각 빈에 대한 트랜잭션 처리, Security 등의 컨테이너적인 기능을 추가하는 것이 가능해진다.


- One Step Ahead -


5. Lightweight 5. Lightweight 아키텍처아키텍처 (5)(5)2. Lightweight 컨테이너 아키텍처의 장단점

장점EJB에 비해 배우기 쉬우며, 빈을 설정하는 방법도 쉽다.

서블릿 컨테이너에서 실행하는 것이 가능하므로 이식성(Portability)이 뛰어나다.

특정 인터페이스에 종속되지 않은 POJO를 기반으로 하기 때문에 테스트가 용이하다.

AOP의 지원으로 EJB 컨테이너에서 지원 가능했던 컨테이너 기능들을 지원하는 것이 가능하다.

OOP 형태로 개발하는 데 제약사항이 없다.

단점분산 환경을 지원하지 못한다.

Lightweight 컨테이너의 가장 큰 단점이다.

그러나 최근 웹 서비스와 같은 분산 환경 기술이 발전하면서 이 부분은 충분히 극복할 수 있다.

아직까지 Lightweight 컨테이너에 대한 표준이 없다.

지금까지 대부분의 개발자들이 Non EJB 아키텍처와 EJB 아키텍처에 친숙한 상태이다.

Lightweight 컨테이너 아키텍처를 새로 배워야 한다는 부담이 있다.


- One Step Ahead -


생각해볼생각해볼 문제문제 (1)(1)최근 Non EJB 프로젝트 경향

EJB를 사용함으로써 발생하는 개발생산성의 저하, 실행속도의 저하와 같은 문제로 인해 프로젝트가 실패하는 경우가 발생했다.

EJB에 대한 환상이 깨지면서 이전에 사용하던 Non EJB 아키텍처를 사용하는프로젝트들이 꾸준히 증가하고 있는 추세이다.

EJB를 사용하다 Non EJB 방식으로 개발을 진행하는 개발자들은 과거처럼 아무것도 없는 상태에서 프로젝트를 진행하는 것이 아니라 각 계층마다 활용이 가능한 프레임워크를 조합하여 사용하는 방향으로 발전하고 있다.

UI 계층

Struts, Webwork 같은 MVC 프레임워크를 기반으로 애플리케이션을 개발

퍼시스턴스 계층

다양한 OR Mapping 프레임워크(Hibernate, iBATIS)

비즈니스 계층

비즈니스 계층에 대한 프레임워크는 사용하지 않는 프로젝트가 아직까지 많은 상태

많은 프레임워크를 하나로 통합할 필요가 있는 상태


- One Step Ahead -


생각해볼생각해볼 문제문제 (2)(2)최근 EJB 프로젝트 경향

EJB 기반으로 진행하는 프로젝트의 실상을 보면 EJB를 왜 사용하는지 이해할수 없는 경우가 많다.

첫 번째, 분산 환경의 경우

EJB 기반으로 애플리케이션을 개발해서 각 컴포넌트들을 각기 다른 서버에 분산해서 운영하는 경우는 거의 없다.

거의 모든 EJB 프로젝트가 모든 컴포넌트를 물리적으로 하나의 서버에 배포하여 운영하고있다.

이는 EJB의 실행 속도 문제 때문에 각각의 컴포넌트를 각기 다른 서버에 분산하지 않고 하나의 서버에 모든 컴포넌트를 배포하게 되는 것이다.

가용성(Scalibility)을 높이기 위해서는 똑같은 컴포넌트들을 가지는 여러 대의 서버를 둠으로써 해결하는 것이 일반적이다.

두 번째, 트랜잭션

EJB 컨테이너의 기능을 활용하기 위하여 EJB를 사용하는 것일까?

EJB 컨테이너 기반 하에서 개발을 하고 있지만 아직까지도 많은 개발자들이 프로그램 내에서 트랜잭션을 처리하는 경우를 많이 볼 수 있다.


- One Step Ahead -


생각해볼생각해볼 문제문제 (3)(3)오픈 소스 진영에서 만들어 내고 있는 많은 프레임워크들은 Non EJB로도 충분히 안정성 있는 애플리케이션을 개발할 수 있다는 확신을 가지도록 만들고있다.


EJB 컨테이너가 가지고 있던 기능들을 모두 포함하면서도 다양한 프레임워크들의 GLUE(연결체) 역할을 하고 있다.

수없이 많은 J2EE API들에 대한 추상 API를 제공함으로써 J2EE API를 더 쉽게사용하는 것이 가능하도록 지원하고 있다.

각 계층에서 어떤 프레임워크를 사용할지, 어떤 자원(Resource)을 사용할지, 심지어 어떤 아키텍처를 사용할지에 대한 결정을 최대한 늦출 수 있는 역할을 해준다.

Spring Spring IoCIoC


- One Step Ahead -


1. 1. 개요개요Spring 프레임워크의 가장 큰 장점

애플리케이션을 개발하기 위하여 필요로 하는 POJO 빈을 프레임워크 자체 내에서 관리해 줌으로써 인스턴스 생성과 생성된 인스턴스들 간의 의존관계를 유연하게 변경하는 것이 가능하도록 지원한다.

향후 확장성을 위해서는 애플리케이션을 개발할 때 특정한 패턴을 이용하여계층 간, 클래스 간의 의존관계를 줄이는 노력을 해야 한다.

Spring 프레임워크를 이용할 경우, 추가적인 클래스 없이도 같은 효과를 얻을 수있다.

IoC(Inversion of Control)Spring 프레임워크의 핵심 기능

IoC 개념만 제대로 이해한다면 Spring 프레임워크가 지원하고 있는 API는 필요할 때 언제든지 다른 문서들을 참고하여 사용하는 것이 가능하다.


- One Step Ahead -


2. 2. IoC(InversionIoC(Inversion of Control) (1)of Control) (1)1. IoC란? (1)

IoC(Inversion of Control, 역제어) – 제어의 역전 현상

객체 생성 및 의존관계에 대한 제어권

자바가 등장한 최초

모든 제어권이 개발자에게 있었음

서블릿, EJB 등장

제어권이 서블릿과 EJB를 관리하는 컨테이너로 넘어가 버림

객체의 생명주기(Life Cycle)를 관리하는 권한 또한 컨테이너들이 전담

서블릿과 EJB 기반 하에서 개발자들은 서블릿, EJB 스펙이 제공하는 대로 애플리케이션을구현할 수밖에 없는 상황으로 바뀜

IoC에서 말하는 “제어권의 역전”이란

객체의 생성에서부터 생명주기의 관리까지 모든 객체에 대한 제어권이 바뀌었다는것을 의미한다.


객체에 대한 생성 및 생명주기를 관리할 수 있는 기능을 제공

즉, 컨테이너 기능을 내부에 포함하고 있음

이와 같은 이유로 Spring 프레임워크를 Spring 컨테이너, IoC 컨테이너라고도 함


- One Step Ahead -



EJB 컨테이너가 EJB의 생명주기를 관리하는 과정

Spring 컨테이너가 POJO의 생명주기를 관리하는 과정

EJB 컨테이너

EJB A EJB B EJB C EJB D

생성 소멸

초기화 서비스

Spring(또는 IoC) 컨테이너

POJO A POJO B POJO C POJO D

생성 소멸

초기화 서비스


- One Step Ahead -



서블릿 컨테이너

서블릿을 관리하기 위한 컨테이너

EJB 컨테이너

EJB를 관리하기 위한 컨테이너

Spring 컨테이너

POJO를 관리하기 위한 컨테이너

Non EJB 아키텍처와 EJB 아키텍처의 단점을 보완하는 방법

POJO 기반으로 애플리케이션 개발을 진행

POJO를 관리할 수 있는 컨테이너를 만들어서 EJB 컨테이너에서 지원하던 기능들을 지원하는 것

서블릿 컨테이너와 EJB 컨테이너

서블릿과 EJB에 대한 제어권만 컨테이너가 담당

객체에 대한 제어권은 개발자들이 직접 담당

Spring 컨테이너

일부 POJO에 대한 제어권만을 가짐

각 계층의 인터페이스를 담당하는 클래스들에 대한 제어권을 가짐

대부분의 POJO에 대한 제어권은 개발자에게 있는 상태


- One Step Ahead -



IoC 컨테이너 분류체계

Martin Fowler“IoC 기능을 Spring 프레임워크의 장점이라고 이야기하는 것은 적합하지 않다”

http://martinfowler.com/articles/injection.htmlLightweight 컨테이너들이 이야기하는 IoC를 Dependency Injection이라는 용어로 사용하는 것이 더 적합하다.

IoCIoC

DLDL

DIDI

Setter InjectionSetter Injection

Constructor InjectionConstructor Injection

Method InjectionMethod Injection

EJBSpring

Spring

IoC : Inversion of ControlDI : Dependency InjectionDL : Dependency Lookup

의존관계를연결시키는

방법에 따른 분류

http://martinfowler.com/articles/injection.html


- One Step Ahead -


2. 2. IoC(InversionIoC(Inversion of Control) (5)of Control) (5)2. DL(Dependency Lookup)

모든 IoC 컨테이너는 각 컨테이너에서 관리해야 하는 객체들을 관리하기 위한 별도의 저장소(repository)를 가진다.


web.xml에서 서블릿을 관리

EJB 컨테이너

ejb-jar.xml에 설정되어 있는 정보들이 JNDI 저장소에 저장되어 관리되고 있음

Spring 컨테이너

POJO들을 관리하기 위하여 별도의 저장소를 가짐

저장소로 XML 파일 또는 Properties 파일을 이용

Properties 파일의 경우에는 Properties 파일 구조가 가지는 한계 때문에 Spring 프레임워크 기반으로 개발하는 거의 모든 애플리케이션은 XML 파일을 POJO 빈을관리하기 위한 저장소로 사용하고 있다.

Dependency Lookup은 저장소에 저장되어 있는 빈(Bean)에 접근하기 위하여 개발자들이 컨테이너에서 제공하는 API를 이용하여 사용하고자 하는 빈(Bean)을 Lookup하는 것을 말한다.

저장소에 있는 빈(Bean)을 Lookup하기 위하여 컨테이너에서 제공하는 API와 의존관계가 발생한다.

컨테이너 API와 의존관계를 많이 가지면 종속성은 증가할 수밖에 없다.


- One Step Ahead -


2. 2. IoC(InversionIoC(Inversion of Control) (6)of Control) (6)3. DI(Dependency Injection) (1)

DI는 Spring 프레임워크에서 새롭게 지원하는 IoC의 한 형태이다.

각 클래스 사이의 의존관계를 빈 설정(Bean Definition) 정보를 바탕으로 컨테이너가 자동적으로 연결시켜 주는 것을 말한다.

컨테이너가 의존관계를 자동적으로 연결시켜 주기 때문에 개발자들이 컨테이너API를 이용하여 의존관계에 관여할 필요가 없게 되므로 컨테이너 API에 종속되는 것을 줄일 수 있다.

개발자들은 단지 빈 설정 파일(저장소 관리 파일)에서 의존관계가 필요하다는 정보를추가하기만 하면 된다.

Spring 프레임워크에서 각 클래스 사이의 의존관계를 관리하기 위한 방법

Setter Injection, Constructor Injection, Method Injection

Setter Injection클래스 사이의 의존관계를 연결시키기 위하여 setter 메소드를 이용하는 방법

Constructor Injection생성자를 통하여 클래스 사이의 의존관계를 연결시킴


- One Step Ahead -


2. 2. IoC(InversionIoC(Inversion of Control) (7)of Control) (7)3. DI(Dependency Injection) (2)

Method InjectionSetter Injection과 Constructor Injection이 가지고 있는 한계점을 극복하기 위하여 Spring 프레임워크 1.1 버전에서 새롭게 지원하고 있는 DI의 한 종류이다.

Singleton 인스턴스와 Non Singleton 인스턴스의 의존관계를 연결시킬 필요가 있을 때 사용할 수 있는 DI의 한 종류이다.

Spring 프레임워크가 기본적으로 빈의 인스턴스를 관리하는 방식은 Singleton이다.

즉, Singleton으로 인스턴스를 한 번 생성하게 되면 이 빈은 재생성 없이 계속해서 재사용된다.

만약 이 상태에서 Singleton 인스턴스와 Non Singleton 인스턴스의 의존관계를연결할 필요성이 생긴다면 어떻게 될까?

Singleton 인스턴스와 Non Singleton 인스턴스가 의존관계로 엮인다고 하더라도 Non Singleton 인스턴스는 항상 Singleton 인스턴스처럼 사용되는 문제점을 가지게 된다.

이와 같은 문제점을 해결하기 위한 방법으로 Method Injection이 탄생하게 되었다.

Spring 프레임워크가 지원하는 DI를 이용할 경우 Spring 프레임워크를 지원하지 않는 다른 개발 환경에서도 얼마든지 이 소스를 재사용하는 것이 가능하다.

Spring 프레임워크가 가지는 가장 큰 장점 중의 하나가 이와 같이 프레임워크나컨테이너에 종속되지 않도록 애플리케이션을 개발하는 것이 가능하다는 것이다.


- One Step Ahead -


3. Spring 3. Spring 프레임워크프레임워크 빈의빈의 생명주기생명주기 (1)(1)1. Spring 프레임워크에서 빈의 생명주기 (1)

Spring 프레임워크의 초기화 및 빈의 생명주기

Spring 프레임워크는 빈 설정 파일(Bean Definition)의 정보를 바탕으로 POJO 빈의 생명주기를 관리한다.

Spring 프레임워크의 빈 설정 파일은 애플리케이션이 시작할 때 한 번 초기화가 진행되며 애플리케이션이 운영되는 동안 초기화된 정보를 계속해서 재사용한다.

Spring 프레임워크에서 빈의 생명주기

빈 설정 파일 정보 초기화빈 설정 파일 정보 초기화

POJO 빈 초기화 상태POJO 빈 초기화 상태

POJO 빈 준비 상태POJO 빈 준비 상태

POJO 빈 소멸 상태POJO 빈 소멸 상태

1. 디폴트 생성자 Invoke

2. 빈의 의존관계 여부 체크3. setXXX() 메소드 호출4. setBeanName() 메소드 호출5. setBeanFactory() 메소드 호출6. setApplicationContext() 메소드 호출7. afterProperties() 메소드 호출8. 빈 설정 파일의 init-method 호출

빈에 대한 초기화가 완료되고서비스 가능한 준비 상태

9. destroy() 메소드 호출10. 빈 설정 파일의 destroy-method 호출


- One Step Ahead -



Spring 프레임워크에서 빈의 생명주기Spring 프레임워크는 먼저 빈 설정 파일의 POJO 빈을 인스턴스화하지 않은 상태로빈 설정 파일 정보를 초기화한다.

빈 설정 파일의 정보를 초기화하면서 XML DTD에 대하여 유효한지를 체크한다.

빈 인스턴스를 생성하면서 의존관계에 있는 빈이 존재하는지의 여부를 체크하여 의존관계에 있는 빈이 존재하지 않는다면 빈의 초기화가 실패한다.의존관계에 있는 빈의 체크가 완료되면 setter 메소드를 호출하거나(Setter Injection의 경우), 생성자의 인자(Construction Injection의 경우)로 실질적인값을 추가하거나, 다른 빈에 대한 레퍼런스(reference)를 전달한다.생성한 빈이 BeanNameAware 인스턴스이면 setBeanName() 메소드를 호출한다.생성한 빈이 BeanFactoryAware 인스턴스이면 setBeanFactory() 메소드를 호출한다.생성한 빈이 ApplicationContextAware 인스턴스이면setApplicationContext() 메소드를 호출한다. 이 과정은 ApplicationContext를이용하여 초기화할 때에만 실핸된다.생성한 빈이 InitializingBean 인스턴스이면 afterProperties() 메소드를 호출한다.생성한 빈의 설정 파일에 init-method가 설정되어 있다면 init-method에 해당하는 메소드를 호출한다.


- One Step Ahead -



Spring 프레임워크에서 빈의 생명주기

애플리케이션이 운영되는 동안 준비상태로 서비스를 진행하다 애플리케이션이 종료될 때 종료 메소드를 호출하면서 빈의 생명을 다하게 된다.

종료 메소드를 호출하는 과정

생성한 빈이 DisposableBean 인스턴스이면 destroy() 메소드를 호출한다.

생성한 빈의 설정 파일에 destroy-method가 설정되어 있다면 destroy-method에 해당하는 메소드를 호출한다.


- One Step Ahead -


3. Spring 3. Spring 프레임워크프레임워크 빈의빈의 생명주기생명주기 (4)(4)2. POJO 빈에서 빈 설정 정보에 접근하기

Spring 프레임워크가 추구하는 방향

POJO 빈이 Spring 프레임워크에 종속적이지 않도록 지원하는 것

그러나 Spring 프레임워크는 관리하는 빈에서 Spring 설정 파일의 정보에 접근할필요가 있다면 특정 인터페이스를 구현함으로써 접근하는 것이 가능하도록 지원하고있다.

BeanNameAware, BeanFactoryAware, ApplicationContextAware 인터페이스

POJO빈에서 위 세 개의 인터페이스 중 접근할 필요가 있다고 생각하는 정보가 있다면 해당 인터페이스를 상속하여 인터페이스에 추가되어 있는 메소드를 구현하기만하면 된다.

그러나 애플리케이션을 개발하면서 Spring 프레임워크 컨테이너 내부에 접근할필요는 거의 없다.


- One Step Ahead -


3. Spring 3. Spring 프레임워크프레임워크 빈의빈의 생명주기생명주기 (5)(5)3. 빈의 생명주기 제어하기

초기화 과정

Spring 프레임워크가 지원하는 인터페이스를 상속하여 초기화를 지원하는 방법

Spring 프레임워크의 인터페이스를 상속함으로써 Spring 프레임워크에 종속되어 버리지만 설정 파일에 추가적인 정보를 추가하지 않아도 된다.

개발자들이 원하는 특정 메소드를 초기화를 위한 메소드로 빈 설정 파일에 추가하는방법

Spring 프레임워크에 종속되지는 않지만 설정 파일에 추가적인 정보를 추가해 주어야 한다.

소멸 과정

Spring 프레임워크에서 지원하는 인터페이스인 DisposableBean을 상속하여destroy() 메소드를 구현하는 방법

특정 메소드를 소멸 과정에 사용하겠다는 정보를 빈 설정 파일에 destroy-method 속성으로 추가해 주는 방법

애플리케이션을 개발하면서 개발자들이 직접 수정하거나 변경할 수 없는 라이브러리에 접근할 때에는 destroy-method를 이용하는 것이 가능하다.


- One Step Ahead -


3. Spring 3. Spring 프레임워크프레임워크 빈의빈의 생명주기생명주기 (6)(6)4. Singleton 빈과 Non Singleton 빈의 관리 방식 (1)

Spring 프레임워크 기반 하에서 관리되는 POJO 빈은 디폴트로 Singleton 방식으로 관리된다.

즉, 애플리케이션에 단 하나의 인스턴스가 존재한다는 것으로 한 번 생성된 인스턴스는 재생성 없이 재사용된다는 것을 말한다.

Spring 프레임워크에서 지원하는 Singleton 인스턴스에 대한 지원

Non EJB 아키텍처에서 많이 사용한 Singleton 디자인패턴을 이용하여 구현하는것이 아니라 애플리케이션 저장소(Repository)를 이용하여 구현하는 방식을 이용하고 있다.

Spring 프레임워크에서 애플리케이션 저장소 역할을 하는 클래스가ApplicationContext이다.

Singleton 인스턴스로 관리되는 모든 POJO 빈은 ApplicationContext 내에 있는HashMap에 키=값(key=value) 쌍으로 저장되었다가 getBean() 메소드를 통하여 빈에 접근하고자 할 때 HashMap에서 빈 인스턴스를 얻게 된다.

Spring 프레임워크는 HashMap을 이용하여 모든 Singleton 인스턴스를 관리하기 때문에 Singleton 인스턴스로 관리하기 위하여 굳이 Singleton 디자인패턴을이용할 필요가 없다.


- One Step Ahead -


3. Spring 3. Spring 프레임워크프레임워크 빈의빈의 생명주기생명주기 (7)(7)4. Singleton 빈과 Non Singleton 빈의 관리 방식 (2)

“Pro Spring”, Rob Harrop/Jan Machack, 2005. Singleton 인스턴스로 관리 가능한 경우

생성되는 인스턴스 내에 공유되는 상태가 없는 경우

생성되는 인스턴스 내에 read-only 상태만 있는 경우

생성되는 인스턴스 내에 공유되는 상태가 있더라도 상태를 변경할 때 동기화(synchronization)를 보장할 수 있는 경우


- One Step Ahead -


4. Spring 4. Spring 프레임워크의프레임워크의 테스트테스트 전략전략 (1)(1)1. 퍼시스턴스 계층(Persistence Layer)에 대한 테스트 전략

퍼시스턴스 계층은 관계형 데이터베이스와 같이 외부 시스템이 있는 환경하에서테스트가 가능하다.

퍼시스턴스 계층을 효율적으로 테스트하기 위해서는 테스트의 전과 후에 영구 저장소의 데이터가 동일한 상태로 유지하는 것이 좋다.

즉, 테스트를 위하여 추가되거나 수정된 데이터는 테스트를 하기 전과 같은 상태로 유지하는 것이 테스트의 독립성을 유지하기 위하여 좋은 테스트 전략이다.

하나의 단위 테스트를 진행할 때 테스트를 완료한 다음 이전 상태와 동일하게 초기화함으로써 각 테스트 메소드간의 독립성을 유지한다.

적은 수의 단위테스트 메소드로도 모든 기능을 테스트하는 것이 가능하다.


- One Step Ahead -


4. Spring 4. Spring 프레임워크의프레임워크의 테스트테스트 전략전략 (2)(2)2. 비즈니스 계층(Business Layer)에 대한 테스트 전략

단위테스트가 가장 필요하고 많은 단위테스트를 진행해야 하는 곳이 실질적인 업무 로직을 담당하고 있는 비즈니스 계층이다.

비즈니스 계층을 단위테스트 할 때에는 정상적으로 업무를 처리하는 경우와 에러가 발생하는 모든 경우의 수까지 철저하게 테스트할 필요가 있다.

철저한 테스트를 진행하기 위해서는 테스트 주기를 가능한 한 짧게 유지하는 것이 좋은 전략이다.

따라서 가능한 한 데이터베이스와 직접적인 통신을 하지 않는 상태에서 테스트가가능하도록 전략을 세우는 것이 좋다.

데이터베이스와 직접적인 통신을 하지 않더라도 비즈니스 계층과 퍼시스턴스 계층사이에 인터페이스만 제대로 설계되어 있다면 비즈니스 계층을 테스트하는 것은 충분히 가능하다.

데이터베이스와의 실질적인 테스트는 비즈니스 계층과 퍼시스턴스 계층의 완성도가 높아진 다음에 통합테스트를 통하여 진행하면 된다.

비즈니스 로직이 포함되어 있는 메소드들에 대해서만 철저하게 테스트를 진행한다.


- One Step Ahead -


4. Spring 4. Spring 프레임워크의프레임워크의 테스트테스트 전략전략 (3)(3)3. Spring 프레임워크 기반 애플리케이션의 테스트 용이성

EJB 아키텍처의 경우 EJB 컨테이너에 배포한 상태에서 테스트를 진행해야 되기 때문에 테스트가 용이하지 않다.

Spring 프레임워크 기반으로 애플리케이션을 개발할 경우 디자인패턴 중Strategy 패턴을 자연스럽게 사용할 수 있음으로 인해서 테스트의 용이성을 높이게 된다.

애플리케이션을 개발할 때 Strategy 패턴을 이용하게 되면 소스 코드의 수정 없이도 테스트하는 것이 가능하다.


- One Step Ahead -


생각해볼생각해볼 문제문제Spring 프레임워크가 가지고 있는 Dependency Injection(SetterInjection, Constructor Injection)은 일관되게 애플리케이션을 개발하도록 지원할 뿐만 아니라 테스트의 용이성까지 보장받을 수 있다는 장점이 있다.

Spring 프레임워크가 가지고 있는 IoC 컨테이너 기능으로 인해 트랜잭션과같이 EJB 컨테이너가 가지고 있는 컨테이너 지원 기능들까지 구현하는 것이가능하다.

IoC 컨테이너에 대한 개념과 Spring 프레임워크가 지원하고 있는 IoC 컨테이너 개념들은 무엇이며, 어떤 종류가 있는가?

IoC 컨테이너 기반으로 개발하게 되면 얻게 되는 장점은 무엇인가?

Spring 프레임워크가 IoC 컨테이너를 지원하는 방법과 컨테이너에서 관리하는 빈의 초기화 및 생명주기 관리는 어떻게 하고 있는가?

Spring 프레임워크 기반으로 애플리케이션을 개발할 경우 단위 테스트는 어떻게 진행할 수 있는가?

Spring AOPSpring AOP


- One Step Ahead -


1. 1. 개요개요애플리케이션을 개발할 때 메소드 내에 핵심적인 비즈니스 로직을 담당하는소스 코드와 Logging, Exception 처럼 비즈니스 로직과는 관계없은 코드들을 같이 구현할 수밖에 없다.

또한 Logging, Exception을 처리하기 위한 소스 코드는 애플리케이션 소스코드의 전체 영역에 걸쳐서 비슷한 패턴으로 중복해서 구현하는 것이 일반적이다.

Logging, Exception과 같이 애플리케이션 전체 영역에 걸쳐서 중복된 소스코드가 존재하고 있기 때문에 Logging, Exception 정책이 바뀔 경우 개발자들은 예제 소스를 일일이 찾아서 수정해 주어야 하는 번거로움을 감수할 수밖에 없다.

OOP가 가지고 있는 한계점을 극복하기 위한 대안으로 등장한 것이AOP(Aspect Oriented Programming)이다.

OOP는 Logging, Exception과 같은 Infrastructure를 처리하기 위하여 가지고 있었던 문제점까지 모두 해결해준 것은 아니다.

AOP는 지금까지의 개발 방식인 OOP 기반 하에서 OOP가 가지고 있는 문제점을 보완하는 역할을 해준다.


- One Step Ahead -


2. AOP2. AOP에서에서 새롭게새롭게 등장한등장한 용어용어Joinpoint

클래스의 인스턴스 생성 시점, 메소드를 호출하는 시점, Exception이 발생하는 시점과 같이 애플리케이션을 실행할 때 특정 작업이 실행되는 시점을 의미

Advice실질적인 비즈니스 로직을 구현하고 있는 ‘핵심 비즈니스 로직 구현부’에 추가적인 기능을제공하는 것

Pointcut분리된 기능들을 결합시키기 위한 규칙(패턴)이 필요했다. 이와 같은 패턴을 Pointcut이라고 한다.

AspectAdvice와 Pointcut을 합쳐서 하나의 Aspect이라고 한다.

즉, 일정한 패턴을 가지는 클래스에 Advice를 적용하도록 지원할 수 있는 것을 Aspect이라고 한다.

Weaving“엮는다, 실로 짠다”

분리된 기능들을 하나로 결합시키는 것을 의미

분리하여 개발된 기능들을 Weaving하는 작업을 도와주는 것이 AOP 툴이 하는 역할이다.

Target실질적인 비즈니스 로직을 구현하고 있는 ‘핵심 비즈니스 로직 구현부’를 의미한다.


- One Step Ahead -


3. AOP3. AOP를를 이용한이용한 효율적인효율적인 개발개발 전략전략 (1)(1)AOP를 적용할 경우 프로젝트 초반에 Exception처리, Logging처리, Transaction처리를 어떻게 구현할지에 대해서는 프로젝트 중, 후반부로 미루어도 된다.

단, 구현하는 애플리케이션에 대한 명명규칙을 확립하고 이에 따라 프로젝트를진행해야 한다.

AOP 사용이 프로젝트에 미치는 영향을 도식화한 그림

AOP를 적용한 프로젝트

AOP를 적용하지 않은 프로젝트

명명규칙

Infrastructure 정책(Logging, Exception)

초반 중반 후반

변경

시

영향력


- One Step Ahead -


3. AOP3. AOP를를 이용한이용한 효율적인효율적인 개발개발 전략전략 (2)(2)하나의 Target 클래스에 너무 많은 Aspect를 적용할 경우 실행속도의 저하를 가져올 수 있다.

Aspect의 사용이 중복 코드를 방지함으로써 많은 부분에서 중복된 개발을 방지하는 것을 사실이지만 무분별한 사용으로 인해 애플리케이션의 실행 속도가 저하될 수 있다.

Aspect는 애플리케이션 개발에 있어서 꼭 필요한 부분에 제한된 범위를 두고서사용하는 것이 바람직하다.


- One Step Ahead -


생각해볼생각해볼 문제문제AOP가 등장하게 된 배경과 OOP와의 관계는 어떠한가?

AOP가 가지는 개념은 무엇인가?

AOP에서 새롭게 등장한 용어들은 무엇을 의미하는가?

AOP를 적용할 경우 프로젝트에 어떤 효과를 줄 수 있는가?

AOP를 프로젝트에 적용할 경우 고려해야 할 사항은 무엇인가?

Spring Spring 트랜잭션트랜잭션


- One Step Ahead -


1. 1. 개요개요 (1)(1)기업 내의 많은 업무들이 시스템에 의하여 자동적으로 처리되면서 가장 중요한 요소로 자리 잡고 있는 부분이 처리되는 데이터에 대한 무결성이다.

애플리케이션 개발에서는 하나의 업무 처리 단위에 따른 데이터의 무결성을보장하기 위하여 트랜잭션(Transaction)이라는 용어를 사용하고 있다

비즈니스 로직이 복잡하지 않은 업무일지라도 트랜잭션을 어떻게 처리할지는애플리케이션 개발에 있어서 큰 비중을 차지하고 있다.

국내 대부분의 웹 애플리케이션 개발에서 트랜잭션 처리를 위하여 구현하고있는 방법은 JDBC 기반 하에서 프로그램적으로 처리하고 있는 경우가 대부분이다.

JDBC 기반으로 트랜잭션을 처리할 경우 비즈니스 계층과 퍼시스턴스 계층 어느곳에서 트랜잭션을 처리해야 할지는 항상 논란거리이다.


이와 같은 문제점을 극복하기 위하여 EJB 컨테이너와 같은 방법으로 트랜잭션기능을 지원하고 있다.

POJO 빈을 기반으로 하고 있기 때문에 EJB 컨테이너를 사용하지 않는 곳에서도 EJB와 같은 방법으로 트랜잭션을 처리하는 것이 가능하다.


- One Step Ahead -


1. 1. 개요개요 (2)(2)문제점

Spring JDBC를 기반으로 개발할 경우 개발자들이 Connection에 직접 접근할 수 없어서 Connection 인스턴스 기반으로 트랜잭션을 처리한 부분이 없다.

해결방법Spring JDBC를 이용할 경우 개발자들은 Connection 인스턴스에 직접적으로접근하지 않는다.

따라서 Connection 인스턴스를 기반으로 트랜잭션을 처리하는 것이 힘들어진다.

Spring 프레임워크는 이와 같은 문제점을 해결하기 위하여 트랜잭션을 처리하기 위한 새로운 API를 제공하고 있다.

Spring 프레임워크의 트랜잭션을 처리하기 위한 방법

소스 코드 내에서 프로그램적으로 처리하는 방법

빈 설정 파일에서 선언적으로 처리하는 방법


- One Step Ahead -


1. 1. 개요개요 (3)(3)트랜잭션 처리

트랜잭션 처리는 관계형 데이터베이스와 같이 하나의 리소스(JDBC Connection이 이용된다) 내에서만 필요한 것이 아니다.

최근에 다양한 시스템 간에 통합이 일반화되면서 하나의 트랜잭션 내에 여러 개의 리소스가 관여하는 경우가 많다.

자바 진영에서는 이 같이 분리되어 있는 리소스의 트랜잭션을 지원하기 위하여JTA 표준을 두고 있다.

JTA 표준을 구현하는 모든 리소스는 하나의 트랜잭션으로 처리하는 것이 가능하다.

Spring 트랜잭션을 이용하여 애플리케이션을 개발할 경우 애플리케이션 개발완료 후 새로운 리소스가 추가되거나 JTA 기반으로 트랜잭션을 변경할 경우 빠른 시간 내에 대응하는 것이 가능하다.


- One Step Ahead -


2. Transaction (1)2. Transaction (1)1. JDBC 기반 트랜잭션 처리 (1)

퍼시스턴스(Persistence) 계층에서 트랜잭션 처리

퍼시스턴스 계층에서 트랜잭션을 처리하는 방법은 일반적으로 많이 사용하는 개발 방법이다.

퍼시스턴스 계층에서 트랜잭션을 관리할 경우

트랜잭션 하에 있는 모든 메소드는 비즈니스 계층에서 호출되는 퍼시스턴스 계층의 첫 번째 메소드에 구현되어야 한다.

퍼시스턴스 계층에서 Connection 생성, Transaction 처리, Connection 반환에 관한 모든 작업을 담당한다.

비즈니스 계층은 단지 퍼시스턴스 계층에 모든 작업을 위임하기만 하면 된다.

복잡한 비즈니스 로직을 포함하지 않는 경우 적합

비즈니스 로직이 복잡하고 애플리케이션의 규모가 큰 경우에는 적합하지 않은 방법


- One Step Ahead -



퍼시스턴스(Persistence) 계층에서 트랜잭션을 처리할 경우 문제점

비즈니스 계층에서 구현되어야 할 비즈니스 로직이 퍼시스턴스 계층에서 구현되는현상이 발생한다.

비즈니스 로직이 복잡하지 않은 경우에는 퍼시스턴스 계층에서 구현하더라도 큰 문제가 되지 않지만 복잡한 경우에는 퍼시스턴스 계층에 비즈니스 로직과 퍼시스턴스구현 로직이 모두 포함되기 때문에 소스 코드가 복잡할 수밖에 없게 된다.

이로 인해 유지보수가 힘들어진다.

Connection 인스턴스를 받는 메소드들과 Connection 인스턴스가 없는 메소드들이 다수 존재하게 된다.

이와 같이 구현될 경우 메소드 호출에 대한 일관성이 없어지기 때문에 퍼시스턴스 계층을 재사용하기 힘들어진다.

비즈니스 로직이 비즈니스 계층과 퍼시스턴스 계층에 분산되어 구현되기 때문에 비즈니스 계층을 재사용하기 힘들 뿐만 아니라 유지보수하기도 힘들어진다.


- One Step Ahead -



비즈니스 계층에서 트랜잭션 처리

비즈니스 계층에서 트랜잭션 처리를 담당하게 될 경우에는 Connection 생성, Transaction 처리, Connection 반환과 관련한 모든 작업을 비즈니스 계층이 담당하게 된다.

Connection에 대한 관리를 비즈니스 계층이 전담하고 있기 때문에 퍼시스턴스 계층의 모든 메소드는 인자로 Connection 인스턴스를 전달할 수 있어야 한다.

트랜잭션 처리를 비즈니스 계층에서 담당하게 될 경우의 장점

비즈니스 계층에서 모든 비즈니스 로직을 구현하는 것이 가능하다.

비즈니스 계층과 퍼시스턴스 계층을 독립적으로 구현하는 것이 가능하므로 각 계층의 재사용성이 높아진다.


- One Step Ahead -


2. Transaction (4)2. Transaction (4)2. 트랜잭션이 처리되어야 하는 위치 (1)

하나의 유스케이스에 해당하는 업무를 처리하는 단위는 비즈니스 계층에서 담당하고 있다.

각 유스케이스에 해당하는 업무들은 비즈니스 계층의 각 메소드 내에서 하나의업무 단위로 구현하게 된다.

그러므로 트랜잭션 처리는 비즈니스 계층의 메소드 단위별로 처리하는 것이 맞다.

비즈니스 계층에서 트랜잭션을 처리하는 것이 각 계층 간의 독립성을 유지할 뿐만 아니라 재사용성을 증가시킨다는 것을 알 수 있다.

그러나 비즈니스 계층에서 트랜잭션을 처리할 경우 트랜잭션 처리를 위한 구현부분이 추가되어야 하기 때문에 비즈니스 계층의 복잡도를 증가시키는 결과를 초래한다.

EJB는 이와 같은 문제점을 해결하기 위하여 선언적으로 트랜잭션을 처리할 수있도록 지원하고 있다.

단지 선언적으로 EJB 설정 파일에서 트랜잭션을 어떻게 처리해야 할지를 설정하기만 하면 된다.

EJB 컨테이너에서 트랜잭션을 처리하는 것이 가능한 이유는 EJB가 등장할 때부터트랜잭션을 하나의 Aspect로 인식하고 AOP 개념이 적용되었기 때문이다.


- One Step Ahead -


2. Transaction (5)2. Transaction (5)2. 트랜잭션이 처리되어야 하는 위치 (2)


프레임워크 자체적으로 AOP 기능을 지원하고 있기 때문에 EJB 컨테이너와 같이 트랜잭션을 선언적으로 처리할 수 있도록 지원하고 있다.

Spring 프레임워크가 지원하고 있는 선언적인 트랜잭션 처리 기능으로 인해 비즈니스 계층은 비즈니스 로직만을 구현하는 것이 가능하게 된다.

트랜잭션에 관한 모든 처리는 빈 설정 파일에서 선언적으로 처리하는 것이 가능하다.

Spring 프레임워크는 프로그램적으로도 트랜잭션을 처리할 수 있도록 지원하고 있다.


- One Step Ahead -


3. Spring 3. Spring 트랜잭션트랜잭션 (1)(1)Spring 프레임워크 트랜잭션 처리

소스 코드 내에서 직접 프로그램을 구현하여 트랜잭션을 처리

빈 설정 파일에서 선언적으로 처리

소스 코드에서 메타데이터를 이용하여 트랜잭션 처리

1. Spring 트랜잭션 기본 (1)트랜잭션의 속성

Atomicity(원자성)트랜잭션 내에 있는 모든 작업이 완료되거나 모든 작업이 완료되지 않아야 한다.

즉, 트랜잭션 내의 작업 중 하나라도 에러가 발생하면 트랜잭션 내의 모든 작업이 롤백(Rollback)되어야 한다.

Consistency(일관성)트랜잭션 중에 오류 없이 유효한 데이터만 데이터베이스에 저장되어야 한다.

Isolation(격리성)트랜잭션 중에 변경된 내용이 트랜잭션이 완료되기 전까지 다른 트랜잭션에 영향을 미쳐서는 안 된다.

Durability(지속성)트랜잭션이 완료된 경우 시스템 고장이나 네트워크 에러 등으로 데이터가 유실되지 않고 정상적으로 기록되어야 한다.


- One Step Ahead -


3. Spring 3. Spring 트랜잭션트랜잭션 (2)(2)1. Spring 트랜잭션 기본 (2)

Spring 프레임워크는 트랜잭션을 지원하기 위해PlatformTransactionManager, TransactionDefinition, TransactionStatus 세 개의 인터페이스를 핵심 API로 사용하고 있다.

TransactionDefinitionTransactionDefinition 인터페이스는 트랜잭션의 네 가지 속성(ACID) 중 개발자들이 제어 가능한 부분을 추상화하고 있다.트랜잭션을 제어하기 위하여 트랜잭션이 가지고 있는 네 가지 속성 전체를 제어하기는 힘들다.

단, 트랜잭션 속성 중에서 트랜잭션 전달(Propagation), time-out, read-only 상태, 격리성(Isolation) 레벨의 네 가지 속성에 대해서 제어하는 것이 가능하다.

TransactionDefinition 인터페이스를 이용하여 다음과 같은 부분을 제어하는 것이 가능하다.

실행하는 트랜잭션이 시작해서 종료할 때까지의 시간을 초 단위로 제어하는 것이 가능하다(getTimeout()).실행하는 트랜잭션이 read-only 상태인지 아닌지를 결정하는 것이 가능하다(isReadOnly()).실행하는 트랜잭션의 격리레벨을 지정하는 것이 가능하다. 즉, 현재 트랜잭션 내에서 변경된데이터가 다른 트랜잭션에 반영될지에 대한 레벨을 결정하는 것이 가능하다(getIsolationLevel()).트랜잭션이 실행되어야 하는 범위에 대한 제어와 여러 개의 트랜잭션이 어떻게 상호작용하는지에 대하여 결정하는 것이 가능하다(getPropagationBehavior()).


- One Step Ahead -


3. Spring 3. Spring 트랜잭션트랜잭션 (3)(3)1. Spring 트랜잭션 기본 (3)

TransactionStatusTransactionStatus는 트랜잭션의 상태를 관리하는 역할을 담당하는 인터페이스

TransactionStatus는 PlatformTransactionManager에서 트랜잭션을Commit할지 Rollback할지를 결정하기 위하여 사용된다.

PlatformTransactionManagerPlatformTransactionManager 인터페이스는 실질적인 트랜잭션을 실행하는 역할을 한다.

트랜잭션 내에서 에러 없이 모든 작업을 완료할 경우에는 Commit, 에러가 발생할경우에는 Rollback 작업을 실행할 수 있도록 지원하고 있다.


- One Step Ahead -


3. Spring 3. Spring 트랜잭션트랜잭션 (4)(4)2. 프로그램적으로 트랜잭션 처리

JDBC 기반 하에서는 Connection 인스턴스를 이용하여 트랜잭션을 처리했다면 Spring 프레임워크에서는 PlatformTransactionManager를 이용하고있다는 점이 다르다.

프로그램적으로 트랜잭션을 처리하는 경우에도 빈 설정 파일의 변경만으로 다양한 리소스에 대한 트랜잭션을 지원하는 것이 가능하므로 향후 확장성을 위해서는큰 장점을 얻을 수 있다.

PlatformTransactionManager 인터페이스 기반으로 트랜잭션을 처리할 경우 트랜잭션에 대한 소스 코드 수정 없이 빈 설정 파일의 변경만으로 Hibernate 프레임워크, JDO, JMS, JTA에 대한 트랜잭션을 지원하는 것이 가능해지기 때문이다.

프로그램적으로 트랜잭션을 처리하는 방법은 트랜잭션에서 필요로 하는 메소드들이 많지 않을 경우에 유용하게 사용할 수 있는 방법이다.

트랜잭션 처리가 복잡하고 빈번한 경우 매번 프로그램적으로 처리하는 것은 상당히 귀찮은 작업일 수밖에 없으며, 많은 중복 코드를 발생시키게 된다.

Spring 프레임워크는 이 같은 단점을 극복하기 위하여 빈 설정 파일에서 선언적으로 트랜잭션을 처리할 수 있도록 지원하고 있다.


- One Step Ahead -


3. Spring 3. Spring 트랜잭션트랜잭션 (5)(5)3. 선언적으로 트랜잭션 처리 (1)

다양한 리소스의 트랜잭션을 처리할 필요가 있거나 처리해야 할 트랜잭션이 많은경우에는 프로그램적으로 처리하는 방법은 상당히 많은 시간을 필요로 한다.

또한 트랜잭션 정책이 바뀌거나 트랜잭션에 대한 변경이 발생하는 경우 소스 코드를 직접 수정해야 하는 단점이 있다.

Spring 프레임워크는 이 같은 문제점을 해결하기 위하여 빈 설정 파일에서 선언적으로 트랜잭션을 처리할 수 있도록 지원하고 있다.

Spring 프레임워크의 선언적인 트랜잭션 처리

Spring AOP를 이용하고 있기 때문에 개발한 소스 코드의 수정 없이 빈 설정 파일의변경만으로 트랜잭션 기능을 추가하는 것이 가능하다.

Spring 프레임워크는 트랜잭션을 지원하기 위한 목적으로TransactionProxyFactoryBean 클래스를 사용하고 있다.

TransactionProxyFactoryBean 클래스는 트랜잭션을 처리하기 위하여 필요한속성들을 정의하는 것이 가능하도록 지원할 뿐만 아니라 트랜잭션 외에 추가적인Aspect를 추가하는 것도 가능하다.


- One Step Ahead -


3. Spring 3. Spring 트랜잭션트랜잭션 (6)(6)3. 선언적으로 트랜잭션 처리 (2)

선언적으로 트랜잭션을 처리할 경우비즈니스 계층의 소스 코드를 변경하지 않고, 설정 파일의 변경만으로 트랜잭션 기능을 추가, 변경하는 것이 가능하다.그러므로 프로젝트의 트랜잭션 정책이 변경되거나 개발 중에 트랜잭션 속성을 변경할 필요가 있을 때 빈 설정 파일만 변경해 주면 된다.이와 같은 작업이 가능한 이유

Spring 프레임워크가 가지고 있는 AOP 기능 때문이다.AOP는 트랜잭션 처리와 같이 Target 클래스의 소스 코드에 대한 변경 없이도 새로운 기능을 추가하는 것이 가능하다.

트랜잭션이 필요한 모든 빈을 선언적으로 처리할 경우 빈의 숫자가 많지 않을 경우에는 크게 문제가 되지 않는다.그러나 중, 대규모 프로젝트에서는 비즈니스 계층을 담당하는 빈의 숫자가 수십, 수백개에 이르게 된다.

이와 같은 경우에 사용할 수 있는 기능이 Spring AOP의 Autoproxying 기능이다.

Spring 프레임워크의 Autoproxying 기능을 이용하여 트랜잭션을 처리하기 위해서는 애플리케이션의 메소드 이름에 대한 명명규칙이 존재해야 하며, 이 명명규칙을기반으로 애플리케이션을 개발해야 한다.명명규칙을 지키지 않았을 경우 일관된 규칙이 없기 때문에 Autoproxying 기능을이용하기 힘들어진다.


- One Step Ahead -


생각해볼생각해볼 문제문제지금까지 EJB 컨테이너 내에서만 가능했던 선언적인 트랜잭션 지원이POJO 빈에도 가능해졌다.

트랜잭션 적용은 비즈니스 로직을 모두 구현한 다음에 POJO 빈 설정 파일을수정하여 적용할 수 있다.

Spring 프레임워크에서 지원하고 있는 트랜잭션과 관련한 기본적인 내용

트랜잭션은 어느 계층에서 처리되어야 하는가?

지금까지 트랜잭션을 처리하기 위하여 많이 사용해왔던 JDBC 기반의 처리 방식이 가지는 문제점과 해결책에 대하여 알아야 한다.

트랜잭션과 관련한 기본적인 개념에 대하여 이해해야 한다.

Spring 프레임워크에서 트랜잭션을 지원하기 위한 핵심 API를 이해해야 한다.

Spring 프레임워크 기반 하에서 프로그램적으로 트랜잭션을 지원하는 방법에대하여 알아야 한다.

Spring 프레임워크 기반 하에서 선언적으로 트랜잭션을 지원하는 방법에 대하여 알아야 한다.

Spring MVC ISpring MVC I


- One Step Ahead -


1. 1. 개요개요웹 애플리케이션이 처음 등장했을 때는 고객들이 원하는 웹 화면을 얼마나 빨리 만들어낼 수 있는지가 프로젝트의 승패를 결정짓는 중요한 요소였다.

그러나 UI 계층에서 너무 많은 기능을 함으로 인해서 유지보수성이 급격하게 저하되었다.

UI 계층은 다른 계층(비즈니스 계층, 퍼시스턴스 계층)과 달리 UI 계층 하나로 분리하여 개발하기에 너무 많은 기능을 포함하고 있다.

상태관리, 웹 페이지의 워크플로우, 입력 값들에 대한 유효성 체크, 에러 처리 등

모델 1 방식으로 UI 계층을 구현할 경우 중복 코드가 무분별하게 발생하는 결과를 초래한다.

기존의 모델 1 에 한계를 느끼게 된 개발자들은 MVC(Model, View, Controller) 모델에 기반한 모델 2 개발 방식이라는 개발방법론을 웹 애플리케이션 개발에 사용하게 되었다.

모델 2를 지원하는 프레임워크

Struts, Spring, Webwork 등

국내 대부분의 프로젝트에서는 Struts를 가장 많이 사용하고 있다.


- One Step Ahead -


2. 2. 모델모델 1 1 개발개발 vsvs 모델모델 2 2 개발개발 (1)(1)1. 모델 1 개발 방식 (1)

사용자들이 전달한 입력 값에 대한 유효성 체크, 비즈니스 계층과의 통신, 화면구성을 위한 프리젠테이션 로직 구현 등의 모든 작업을 JSP에서 전담하게 됨

Servlet Container

JSP

웹

브라우저

자바빈

1

42

3

요청

응답

DB

애플리케이션 서버 엔터프라이즈 서버/

데이터 소스


- One Step Ahead -



장점초기 개발 속도가 빠르다.

웹 애플리케이션 개발을 처음 시작하는 개발자들도 쉽게 접근할 수 있다.

단점초기 개발속도가 빠른 반면 프로젝트 중, 후반부로 갈수록 요구사항 변경에 따른 대응속도가 느리다.

JSP에서 너무 많은 일을 전담하고 있으므로 JSP 파일이 너무 복잡해져 유지보수하기 힘들다.

정교한 UI 계층을 개발하는 것이 힘들다.JSP에서 모든 일을 전담하고 있기 때문에 유효성 체크, 에러 처리, 다국어 지원 등과 같이UI 계층을 정교하게 개발하기 힘들다.

서블릿 컨테이너에 종속되어 있기 때문에 서블릿 컨테이너에 배포한 상태에서만 UI 계층을 테스트하는 것이 가능하다.

그러므로 테스트하기 힘들다.

다음과 같은 경우 굳이 모델 2를 적용할 필요는 없다.개발 기간은 짧은데 모델 2로 개발한 경험이 없는 개발자들과 같이 일할 경우

개발하는 애플리케이션의 규모가 작을 경우

잦은 변경이나 요구사항 변경이 많지 않은 경우


- One Step Ahead -



MVC 개념은 애플릿과 같은 GUI 개발에서 사용하던 개념이다.MVC 개념을 웹 애플리케이션에 도입하고자 하는 시도가 모델 2이다.

클라이언트 요청이 모델 2로 처리되는 세부 과정모델 2에서의 모든 요청은 제일 먼저 컨트롤러인 서블릿으로 진입하게 된다.컨트롤러는 클라이언트의 요청을 받아 비즈니스 계층에 작업을 위임한다.컨트롤러가 비즈니스 계층에 작업을 위임할 때 클라이언트로부터 전달된 데이터(모델)를 같이

전달하게 된다.비즈니스 계층이 작업을 완료한 다음 컨트롤러에 결과물을 반환한다.컨트롤러는 비즈니스 계층으로부터 반환된 결과물(모델)의 상태와 클라이언트가 전달한 인자

에 따라 클라이언트에게 출력할 뷰(JSP)를 결정한다. 호출되는 뷰에는 모델로부터 반환된 결과물(모델 데이터)을 같이 전달한다.

뷰(JSP)는 최종적으로 컨트롤러로부터 전달된 결과물을 클라이언트에게 보여준다.

Servlet Container

<<Controller>>

Servlet웹

브라우저

<<View>>

JSP

1

5

3

<<Model>>

자바빈4

2요청

응답

인스턴스생성

애플리케이션 서버 엔터프라이즈 서버/

데이터 소스

DB


- One Step Ahead -



장점정교한 UI 계층의 개발이 가능해진다.

모든 요청이 컨트롤러를 거치기 때문에 컨트롤러를 통하여 화면에 대한 정교한 제어가 가능하며, 에러 처리, 유효성 체크 등의 기능을 컨트롤러가 담당하게 된다.

JSP는 단지 프리젠테이션을 위한 로직만을 가지고 있기 때문에 구현 코드가 단순해진다.

그러므로 유지보수성이 향상된다.

뷰를 위한 기술로 JSP 만이 아닌 XML, Velocity와 같은 다양한 기술들을 이용하는것이 가능해진다.

컨트롤러에 대한 테스트는 서블릿 컨테이너에 배포하지 않아도 테스트가 가능해진다.그러므로 테스트가 쉬워진다.

최종 뷰에 대한 테스트는 여전히 서블릿 컨테이너에 배포한 상태에서 진행해야 한다.

단점모델 1에 비하여 배우는 데 많은 시간을 투자해야 한다.

새로운 기술을 익혀야 한다는 부담감이 있다.


- One Step Ahead -


3. Spring MVC 3. Spring MVC 기본기본 (1)(1)Spring MVC는 웹 애플리케이션 개발에 유연성을 더하기 위하여 많은 옵션들을 가지고 있기 때문에 복잡하게 느낄 수 있다.

클라이언트의 요청을 처리하는 과정 (1)Spring MVC는 하나의 요청을 처리하기 위하여 여러 단계를 거치게 된다.

Spring MVC에서 요청에 대한 생명주기

DispatcherServlet

요청

HandlerMapping

Controller

ModelAndView

ViewResolver

View


- One Step Ahead -


3. Spring MVC 3. Spring MVC 기본기본 (2)(2)클라이언트의 요청을 처리하는 과정 (2)

클라이언트의 요청이 처음으로 진입되는 지점은 DispatcherServlet이다( ).DispatcherServlet은 Spring MVC에서 가장 핵심적인 기능을 구현하고 있는 클래스로서 하나의 요청을 처리하기 위하여 필요한 클래스들의 중계를 담당하는 역할을 한다.

클라이언트로 부터 요청이 들어오면 DispatcherServlet은 빈 설정 파일에 정의되어 있는 HandlerMapping을 이용하여 요청 URL에 해당하는Controller 객체를 얻게 된다( ).

빈 설정 파일에 정의되어 있는 Controller는 일반적으로 요청 URL을 기반으로 정의되어 있다.

따라서 HandlerMapping은 요청 URL에 매핑되어 있는 Controller를DispatcherServlet에 반환하게 된다.

DispatcherServlet은 HandlerMapping으로부터 Controller를 얻게 되면요청에 대한 모든 작업을 Controller에게 위임하게 된다( ).

Controller는 Spring MVC를 구현하기 위하여 개발자들이 직접 구현을 담당하게되는 부분으로 클라이언트로부터 전달된 인자에 대한 유효성 검증 작업, 비즈니스 계층과의 통신, 비즈니스 계층에서 발생한 에러에 대한 처리, 작업 완료 후 이동하게 될뷰화면 등에 대한 모든 처리를 담당하게 된다.


- One Step Ahead -


3. Spring MVC 3. Spring MVC 기본기본 (3)(3)클라이언트의 요청을 처리하는 과정 (3)

Controller는 비즈니스 계층과의 통신을 완료한 다음 비즈니스 계층에서 전달된 모델 데이터와 클라이언트에게 보여줄 뷰화면에 대한 정보를ModelAndView 클래스에 담아서 DispatcherServlet에 반환하게 된다( ).

DispatcherServlet으로 전달된 ModelAndView 클래스의 View 정보는 View 객체(View Object) 또는 논리적인 View 이름(String)을 가지게 된다.

ModelAndView 클래스에 저장되어 있는 View 정보가 View 객체를 통하여Controller에서 반환되었다면 DispatcherServlet은 View 객체를 이용하여클라이언트 화면을 출력하게 된다( ).

그러나 ModelAndView에 저장되어 있는 View 정보가 논리적인 View 이름일 겨우에는 빈 설정 파일에 정의되어 있는 ViewResolver 클래스를 이용하여 클라이언트에게 출력할 View 객체를 얻게 된다( ).


- One Step Ahead -


생각해볼생각해볼 문제문제최근에는 많은 웹 애플리케이션의 UI 계층을 MVC로 분리하여 개발하는 경향이 나타나고 있다.

대표적인 역할을 한 프레임워크가 스트럿츠

Struts FrameworkUI 계층을 각 역할에 따라 분리하고 있음

JSP는 단지 비즈니스 계층에서 전달된 모델 데이터를 출력하는 역할만을 담당하고 있음

UI 계층을 얼마나 유연하고 유지보수 가능하도록 구현하느냐에 따라 웹 애플리케이션의 승패가 달려있다.

Spring MVC는 Struts와 더불어 UI 계층 개발을 지원하기 위한 MVC 프레임워크이다.

지금까지 개발자들이 하드 코딩했던 많은 부분들을 지원하고 있으며, UI 계층을좀 더 정교하게 개발하는 것이 가능하도록 지원하고 있다.

Spring MVC IISpring MVC II


- One Step Ahead -


1. 1. 개요개요지금까지 웹 브라우저에 국한되었던 웹 애플리케이션이 다양한 기기의 등장으로 하나의 애플리케이션에서 다수의 브라우저를 지원할 필요성을 요구 받고있다.

또한 국제화가 가속화되면서 하나의 언어만을 지원하는 것이 아니라 여러 개의 언어를 지원할 필요성이 제기되고 있다.

UI 계층을 유연하고 확장 가능하도록 구현하는 것이 웹 애플리케이션의 중요한 화두가 되고 있는 것이 지금의 상황이다.

Spring MVC는 UI 계층을 유연하고 확장 가능하도록 지원하기 위하여 다양한 기능들을 제공하고 있다.

Spring MVC의 다국어 지원 기능

Spring MVC의 유효성 체크 기능

서버 측과 클라이언트 측에서 유효성 체크

JSP 대신 Velocity로 샘플 애플리케이션을 개발함으로써 Spring MVC에서 새로운 UI 기술을 쉽게 적용

Spring MVC를 이용하여 구현할 때의 테스트 전략과 에러 처리 전략


- One Step Ahead -


2. 2. 각각 계층계층 사이에서사이에서 모델모델 데이터를데이터를 전달하는전달하는 방법방법 (1)(1)애플리케이션을 개발할 때 각 계층 사이에서 데이터를 어떻게 주고받을지에대한 전략을 세우는 것이 중요하다.

전략이 어떻게 수립되느냐에 따라 개발 시의 생산성과 유지보수 용이성에 큰 영향을 미친다.

EJB 아키텍처

각 계층 사이의 데이터를 전달하기 위한 방법

도메인 모델 데이터를 직접 전달하지 않고 DTO(Data Transfer Object) 또는VO(Value Object)와 같은 새로운 모델 클래스를 생성하여 전달할 것을 Best Practice로 추천하고 있다.

“Core J2EE Patterns” 책에서는 DTO 또는 VO를 사용하는 것을 하나의 패턴으로 정의하여 개발자들로 하여금 적극적으로 사용하도록 해왔다.

이 패턴은 EJB를 사용하지 않는 Non EJB 아키텍처에서도 남용되고 있다.

도메인 모델과 DTO 모델을 사용하여 데이터를 전달하는 방법


DTO 모델 도메인 모델


- One Step Ahead -


2. 2. 각각 계층계층 사이에서사이에서 모델모델 데이터를데이터를 전달하는전달하는 방법방법 (2)(2)애플리케이션을 개발하면서 도메인 모델 클래스 외에 별도의 DTO 클래스를둘 경우 다음과 같은 문제점이 발생한다.

도메인 모델에서 DTO 모델로, DTO 모델에서 도메인 모델로 데이터를 전달하는과정에서 데이터가 유실될 수 있다.

이와 같은 문제로 인해서 버그가 발생할 경우 디버깅하는 데 상당히 많은 시간이 소요된다.

도메인 모델에서 DTO 모델로, DTO 모델에서 도메인 모델로 데이터를 전달하기위한 추가적인 작업이 발생함으로써 추가적인 개발 비용이 발생한다.

관리해야 할 클래스가 많아짐으로써 유지보수가 힘들어지게 된다.프로젝트에 따라 다르지만 DTO 클래스의 수가 도메인 클래스 수의 두세 배 이상이되는 경우도 볼 수 있다.

DTO를 구현하는 일은 단순 반복적인 작업이다.이 같은 단순 반복적인 작업은 개발자들의 개발 의욕을 저하시킨다.


- One Step Ahead -


2. 2. 각각 계층계층 사이에서사이에서 모델모델 데이터를데이터를 전달하는전달하는 방법방법 (3)(3)EJB를 사용하지 않는 Non EJB 아키텍처와 Lightweight 컨테이너 아키텍처에서는 계층 사이의 데이터를 전달하기 위하여 도메인 모델 클래스 외에 별도의 DTO를 만들 필요가 없다.

각 계층 사이의 메소드 호출을 몇번 더 실행한다고 해서 추가적인 비용이 거의 발생하지 않는다.

도메인 모델만을 이용하여 데이터를 전달하는 방법

도메인 모델 클래스를 Spring MVC 데이터 바인딩에서부터 퍼시스턴스 계층에서 데이터베이스와의 통신을 담당하는 전 영역에서 사용하는 것이 애플리케이션개발 생산성 및 유지보수를 향상시킬 수 있는 좋은 방법이다.

Spring 프레임워크를 기반으로 프로젝트를 진행할 경우

도메인 모델을 전 영역에서 사용하는 것을 기본 원칙으로 하고, DTO가 필요한상황이 발생한다면 그때만 DTO를 사용하도록 한다.


도메인 모델


- One Step Ahead -


3. UI 3. UI 계층계층 테스트테스트 전략전략 (1)(1)대부분의 프로젝트에서 비즈니스 계층 개발자와 UI 계층 개발자가 서로 다른경우가 많다.

이와 같은 경우 대부분의 개발자들이 개발을 같이 시작하는 경우가 많은데 UI 계층 개발자들은 비즈니스 계층이 구현된 상태가 아니기 때문에 테스트를 진행하기힘든 경우가 많다.

그런데 비즈니스 계층의 구현이 끝나기만을 기다린 후에 테스트를 시작한다는 것은 비효율적인 작업이며, 프로젝트 막바지에 이르러서 UI 계층 개발자에게 너무큰 부담을 안기를 결과를 초래한다.

따라서 UI 계층은 비즈니스 계층의 구현 여부에 관계없이 테스트를 진행하는 것이 무엇보다도 중요하다.

UI 계층에서 테스트에 대한 독립성을 유지하기 위해서는 먼저 UI 계층과 비즈니스 계층 사이에서 사용할 인터페이스가 정의되어야 한다.

비즈니스 계층을 설계하고 구현하는 개발자는 비즈니스 계층에서 구현할 인터페이스를 UI 계층 개발자에게 제공해야 한다.

UI 계층 개발자들은 이 인터페이스를 바탕으로 테스트를 진행해야 한다.


- One Step Ahead -


3. UI 3. UI 계층계층 테스트테스트 전략전략 (2)(2)Spring 프레임워크는 UI 계층의 테스트를 지원하기 위하여 Mock 클래스들을 두고 있다.

Mock 클래스는 Spring 프레임워크 배포판의 dist 디렉토리 아래에 spring-mock.jar 라이브러리로 제공하고 있다.

Mock 라이브러리에서 대표적으로 지원하는 클래스는 서블릿 API를 구현하는Mock 클래스들이다.

웹 애플리케이션을 개발하면서 가장 테스트하기 힘든 부분이 UI 계층의 테스트이다.

다른 계층에서는 JUnit과 같은 테스트 프레임워크를 이용하여 단위테스트를 자동화하는 것이 가능하다.

UI 계층은 서블릿 컨테이너에 종속되기 때문에 단위테스트를 자동화하기가 힘들다.

그러나 Spring MVC 와 같이 모델 2 개발 방식으로 UI 계층을 분리할 경우 서블릿컨테이너에 배포하지 않은 상태에서도 테스트 하는 것이 가능해진다.

최종적으로 모델 데이터를 출력하는 JSP 또는 Velocity에 대한 테스트는 서블릿 컨테이너에 종속되기 때문에 자동화하기 힘들다.


- One Step Ahead -


3. UI 3. UI 계층계층 테스트테스트 전략전략 (3)(3)Spring MVC를 이용한 UI 계층 테스트 전략

UI 계층의 구현에 필요한 대부분의 작업

Controller와 프레임워크가 담당하도록 구현

JSP 또는 Velocity모델 데이터에 대한 출력만을 담당하도록 구현


- One Step Ahead -


생각해볼생각해볼 문제문제Spring 프레임워크는 웹 애플리케이션의 특정 계층만을 지원하기 위한 프레임워크가 아니다.

Spring MVC는 지금까지 등장했던 웹 프레임워크들의 장점들을 모두 수용하기위해 노력했다.

Spring 프레임워크는 하나의 애플리케이션을 구축하기 위하여 필요한 모든기능을 지원하고 있다.

애플리케이션 개발을 위하여 필요한 모든 기능을 Spring 프레임워크가 자체적으로 구현하는 것이 아니라 이미 존재하는 많은 라이브러리들을 Spring 프레임워크와 일관된 방법을 통합시킴으로써 그 시너지 효과를 극대화하고 있다.

Spring 프레임워크는 개발되는 애플리케이션을 Spring 프레임워크 API에종속되지 않도록 최대한 지원하고 있다.

향후 Spring 프레임워크가 아닌 다른 프레임워크 기반 하에서도 재사용이 가능하도록 개발하는 것을 가능하도록 도와주고 있다.

또한 아키텍처의 변경으로 EJB가 사용될 경우

Spring 프레임워크는 유연하게 대응할 수 있도록 지원하고 있다.

SpringSpring과과 EJBEJB


- One Step Ahead -


1. 1. 개요개요Spring 프레임워크

EJB가 가지고 있는 문제점을 일부분이라도 해결하기 위하여 EJB에 대한 추상API를 제공한다.

Spring 프레임워크가 EJB 개발을 지원하기 위하여 추구하는 전략

EJB를 단순히 분산 환경을 지원하기 위한 용도로만 사용한다.

실질적인 비즈니스 계층과 퍼시스턴스 계층

Spring 프레임워크 기반으로 개발

EJB는 클라이언트와의 인터페이스만을 담당

Spring 프레임워크 기반으로 EJB를 개발할 경우

EJB가 가지고 있던 많은 문제점을 해결할 수 있다.


- One Step Ahead -


2. 2. 애플리케이션애플리케이션 아키텍처아키텍처 (1)(1)애플리케이션이 분산 환경을 지원하기 위하여 EJB를 사용할 경우

EJB는 단순히 외부 분산시스템과의 인터페이스만을 담당하는 역할을 한다.

애플리케이션 EJB를 적용했을 때의 기본 아키텍처

DB

Spring 컨테이너

MySQL 데이터베이스

사용기술

POJOBean

SpringJDBC

Spring MVCSitemeshJSP, Velocity

UI 계층(Presentation Layer)

EJB(FAÇADE)

비즈니스 계층(Business Layer)

퍼시스턴스 계층(Persistence Layer)

JBoss WAS


- One Step Ahead -


2. 2. 애플리케이션애플리케이션 아키텍처아키텍처 (2)(2)애플리케이션 EJB를 적용했을 때의 기본 아키텍처

EJB는 외부시스템이나 UI 계층과의 인터페이스만을 담당

EJB가 담당해 왔던 비즈니스 계층과 퍼시스턴스 계층

Spring 프레임워크 기반 하에서 개발

비즈니스 계층의 트랜잭션 기능

Spring 프레임워크의 트랜잭션을 그대로 사용하여 구현


- One Step Ahead -


3. Spring 3. Spring 프레임워크프레임워크 기반기반 하에서하에서 분산분산 환경환경 지원지원 전략전략 (1)(1)Spring 프레임워크가 가지고 있는 가장 큰 단점

분산 환경을 지원할 수 없다.

Spring 프레임워크로 구현되어 있는 애플리케이션을 분산 환경이 지원 가능하도록 구현하는 데 많은 비용이 발생하지 않는다.

EJB, 웹 서비스를 이용하여 분산 환경을 지원해야 하는 애플리케이션을 개발할 때

Spring 프레임워크를 이용한다면 큰 효과를 얻을 수 있다.

분산환경을 지원하는 애플리케이션이라 하더라도 애플리케이션의 모든 기능은 Spring 프레임워크 기반 하에서 개발한 다음 EJB, 웹 서비스는 단순히 클라이언트와 인터페이스만 하도록 구현한다면 개발생산성, 테스트의 용이성을크게 향상시킬 수 있다.

Spring 프레임워크가 가지고 있는 개발생산성, 테스트의 용이성을 최대한 활용함으로써 분산환경 기술들이 지금까지 가지고 있었던 문제점을 해결할 수 있다.


- One Step Ahead -


3. Spring 3. Spring 프레임워크프레임워크 기반기반 하에서하에서 분산분산 환경환경 지원지원 전략전략 (2)(2)분산환경을 지원해야 하는 애플리케이션일지라도 Spring 프레임워크를 이용하여 Lightweight 컨테이너 아키텍처 기반으로 애플리케이션의 모든 기능을먼저 구현한다.

Lightweight 컨테이너 아키텍처 기반으로 애플리케이션 개발

DB

Spring 컨테이너

MySQL 데이터베이스

사용기술

POJOBean

SpringJDBC

Spring MVCSitemeshJSP, Velocity

UI 계층(Presentation Layer)

비즈니스 계층(Business Layer)

퍼시스턴스 계층(Persistence Layer)



- One Step Ahead -


3. Spring 3. Spring 프레임워크프레임워크 기반기반 하에서하에서 분산분산 환경환경 지원지원 전략전략 (3)(3)Lightweight 컨테이너 아키턱처 기반으로 애플리케이션을 개발하더라도 애플리케이션에 필요한 모든 기능들을 고객에게 시연하는 것이 가능하다.고객 시연 후 발생하는 고객들의 요구사항이 대부분 애플리케이션에 반영된다음에 분산환경을 지원하기 위한 추가 작업을 하면 된다.EJB와 웹 서비스

클라이언트와의 인터페이스만을 담당

모든 비즈니스 로직Spring 프레임워크의 POJO 빈에서 구현

프로젝트를 시작해서 애플리케이션의 완성도가 적정 단계에 도달하기까지는모든 구현을 Lightweight 컨테이너 아키텍처 기반으로 구현한다.클라이언트의 추가적인 요구사항이나 변경이 발생하지 않는 단계에 다다르면분산환경을 지원하기 위한 추가 구현을 시작한다.분산환경지원까지 모두 완료한 다음에도 고객으로부터 요구사항이 변경될 경우

Lightweight 컨테이너 아키텍처 기반 하에서 변경 및 테스트를 진행한 다음 분산아키텍처로 배포하는 방식으로 개발을 진행하는 것이 개발생산성의 향상을 가져온다.

이 과정에서 분산 기능을 지원하기 위하여 추가적으로 구현할 부분에 대한 테스트 및가이드라인은 프로젝트 초반에 진행되어 있어야 한다.


- One Step Ahead -


3. Spring 3. Spring 프레임워크프레임워크 기반기반 하에서하에서 분산분산 환경환경 지원지원 전략전략 (4)(4)분산 환경을 지원하는 애플리케이션을 개발할 때의 개발 프로세스

애플리케이션 기능 구현/변경애플리케이션 기능 구현/변경

클라이언트에게 데모 시현클라이언트에게 데모 시현

Lightweight 컨테이너 아키텍처

개발 완료개발 완료

요구사항 변경이 있는가?요구사항 변경이 있는가?

분산 환경 추가 구현분산 환경 추가 구현

클라이언트에게 데모 시현클라이언트에게 데모 시현

분산 아키텍처

요구사항 변경이 있는가?요구사항 변경이 있는가?

애플리케이션기능 변경/테스트

애플리케이션기능 변경/테스트

아니오

아니오

예

예


- One Step Ahead -


생각해볼생각해볼 문제문제 (1)(1)최근 J2EE 환경의 가장 큰 화두는 SOA(Service Oriented Architecture)이다.

SOA가 추구하는 방향

웹 서비스를 근간으로 해서 다양한 시스템 간의 통합을 가능하게 하겠다는 것

이미 각 기업에 구축되어 있는 애플리케이션을 효율적으로 통합함으로써 각 애플리케이션의 더 많은 업무를 컴퓨터가 자동적으로 처리하도록 지원하겠다는 것

각 애플리케이션 간의 인터페이스를 가능하도록 지원하기 위해서는

분산 환경을 지원할 수 있는 EJB, 웹 서비스와 같은 기술이 기존의 애플리케이션에추가 구현되어야 한다.

그러나 EJB 기반으로 구축된 애플리케이션조차 비즈니스 계층을 명확하게 분리하고있다고 하지만 EJB 컨테이너에 종속되어 있는 세션빈에 구현되어 있으므로 재사용하는 것이 힘들 실정이다.

이 같은 문제점을 해결하기 위해서는 어떠한 분산 기술을 적용하더라도 비즈니스계층을 재사용 가능하도록 구축하는 것이 중요하다.

Spring 프레임워크는 POJO 빈을 이용하여 비즈니스 계층을 전담하게 함으로써 비즈니스 계층의 재사용성을 극대화하고 있다.


- One Step Ahead -


생각해볼생각해볼 문제문제 (2)(2)Spring 프레임워크가 추구하는 방향

가능한 한 프레임워크 종속적이지 않은 상태로 애플리케이션을 개발하도록 하는

것

어떤 다른 기능보다도 Spring 프레임워크가 추구하고 있는 이 같은 방향이 애플리케이션의 유연성과 확장성을 극대화한다.


- One Step Ahead -


참고문헌참고문헌Spring 프레임워크 레퍼런스 문서

http://www.springframework.org/docs/reference/index.html

위 문서에 대한 번역본

http://openframework.or.kr/framework_reference/spring/ver1.2.2/html/

Spring 프레임워크 레퍼런스 문서 메일 추상화 API 사용 방법에 관한 문서

http://www.springframework.org/docs/reference/mail.html

위 문서에 대한 번역본

http://openframework.or.kr/framework_reference/spring/ver1.2.2/html/mail.html

Bean Factory와 ApplicationContext API 사용 방법

http://www.springframework.org/docs/reference/beans.html#beans-basics

JUnit 테스트 프레임워크의 기본적인 사용법

http://junit.sourceforge.net/doc/testinfected/testing.htm









http://junit.sourceforge.net/doc/testinfected/testing.htm


- One Step Ahead -


참고문헌참고문헌모의 객체 프레임워크

http://www.easymock.org

http://www.easymock.org/Documentation.html

http://www.easymock.org/

http://www.easymock.org/Documentation.html

감사합니다감사합니다

Date post:	24-Feb-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	1 times

Spring 프레임워크 워크북pds13.egloos.com/pds/200901/14/88/a0105788_496df5c348c8f.pdf ·...

Documents