2. 아키텍처 상에서 Spring 프레임워크가 차지하는 위치

아키텍처 – EJB 등장 이후 변화

IT 환경이 계속해서 발전하면서 개발 기간이 점점 더 짧아지고 있다 . 클라이언트들이 유지 보수성의 중요성에 대한 인식 증대 개발 Process 에서 Test 의 중요성이 증가 => Test 의 용이성 필요 한 회사내에서는 일관된 개발 Framework 의 필요성 요구 AOP, Web Service 기술의 안정화 . IOC 패턴을 지원하는 Light Weight Container Framework 의 등장 : Spring,

PicoContainer, HiveMind O/R Mapping, JDO 안정화 : JDO 2.0 스펙정의 , Hibernate, Ibatis 등 다양한 Open Source 의 등장 : Eclipse, Beehive, Jboss, Spring, Struts 등 WEB 에 C/S 개념을 적용 시키기 위한 다양한 기술 등장 – AJAX, Flex 와

같은 다양한 RIA(Rich Internet Applications) 등장

아키텍처 - Classic EJB Architecture

장점 정형화된 Service Layer 제공 선언적인 Transaction 관리와

같은 EJB 서비스 제공 Business Object 를 여러 서버에

분산이 가능 많은 개발자들이 개발에 익숙한

상태

단점 실행속도와 개발속도등 여러

부분에서 상당한 overhead 가 발생함 .

OO(Object Oriented) 의 제한된 구현만이 가능함 .

테스트하기 어려움 . 항상 EJB Container 에서만 테스트가 가능함 .

아키텍처 - Local EJB Architecture

장점 분산환경을 제외한 Remote EJB

아키텍처의 모든 강점을 제공 RemoteException 을 처리하지

않아도 됨

단점 Remote 분산환경을 제공하지

않음 테스트하기 어려움 . 항상 EJB Co

ntainer 에서만 테스트가 가능함 . 아키텍처가 여전히 복잡함 .

아키텍처 - Non EJB Architecture

장점 Servlet Engine 에서 서비스 가능 . - Cheape

r License, Easier administration. Application Server, Servlet Engine 에 대해

더 좋은 Portability. Simpler Implemenation - POJO business O

bject, No JNDI lookup 번거로웠던 Deployment descriptors 가

필요없음 Quicker code-deployment cycle. 단지 war

파일 하나만 deploy 하면 됨

단점 Remote 분산환경에 대한 지원이 부족 . 표준화된 환경과 관리 부족 . 유지 보수의

어려움 . Business Service Layer 에 대한 불명확함 . EJB 의 선언적인 Transaction 관리와 같이

미리 제공하는 기능이 없음 . 필요한 기능이 있을 때마다 구현 필요 .

Application 이 점점 커짐에 따라 Application 의 일관성 부재

Testability 가 EJB 보다 좋을 수 있으나 경우에 따라 다름 .

아키텍처 - Lightweight Container Architecture

장점 A simple but powerful Horizontal scalability 는 높음 . EJB 보다 배우기 쉬우며 , Configuration

또한 쉽다 . AOP 의 지원으로 인해 선언적인 Transac

tion 관리와 같이 EJB 에서 지원하던 기능들의 지원이 가능함 .

Servlet Engine 에서 실행이 가능함 . Application Server 와 Servlet Engine 의

Portability 높음 . IOC(Inversion of control) 을 통한 Busine

ss Object 의 관리가 용이함 . POJO 임으로 Testability 가 높음 . OOP 의 제한이 없음 .

단점 Remote 분산환경을 지원하지 않음 . We

b service 를 통하여 해결 가능 . 현재 Lightwegiht Container 에 대한

표준이 없음 . EJB 아키텍트와 개발자들에 친숙하지

않음 .

아키텍처 – Lightweight Container Architecture 의 예

최근 중 , 대규모의 웹 애플리케이션 효율적으로 개발 및 유지보수 하기 위하여 계층화 (Layering) 하는 것이 일반적

보통 이 Layer 는 프리젠테이션 , 퍼시스턴스 , 비즈니스 , 도메인 모델 (Domain model) Layer 4 개로 나눈다 .

각 Layer 는 완전히 독립적이어야 하며 , 일반적으로 각 Layer 사이에서는 인터페이스를 통하여 통신한다 .(Domain Model 의 경우에는 제외 )

아키텍처 – Presentation Layer

Presentation Layer 에서 제공해야 하는 기능 사용자를 위한 request 와 response 의 처리 비즈니스 로직과 다른 상위 프로세스로의 호출을 웹 환경으로부터

분리하기 위한 컨트롤러 제공 상위 Layer 에서 발생하는 Exception, Error 에 대한 처리 View 에 표현해야할 Model 을 엮는 기능 View 에서 입력한 데이터에 대한 유효성 검증 (Validation) 기능

사용가능한 Framework Struts Spring MVC JSF(Java Server Faces) WebWork JSP + Servlet 기타 무수히 많은 Framework 존재

아키텍처 – Business Layer

Business Layer 에서 제공해야 하는 기능 어플리케이션 비즈니스 로직 처리와 비즈니스에 관련된 빈의 적합성 검증

트랜잭션 처리 다른 계층들과 통신하기 위한 인터페이스 제공 비즈니스 레벨에 있는 객체들간의 관계를 관리 프리젠테이션 계층과 퍼시스턴스 계층 사이의 다리 역할을 해 그 둘이

직접 통신하지 않도록 함으로써 어플리케이션에 유연성을 더함 . 사용가능한 Framework

Spring Pico Container EJB Session Bean

아키텍처 – Persistence Layer

Persistence Layer 에서 제공해야 하는 기능 관계형 정보를 빼내어 객체화 시키는 작업 . 데이터베이스의 자료를 저장하고 , 수정하고 , 삭제하는 작업 .

Persistence Layer 에서 넣지 말아야 하는 기능 비즈니스 로직 . Persistence Layer 는 단지 데이터 접근과 관련된 기능만

제공해야 함 . Presentation 로직과 Persistence 로직을 같이 사용하면 안된다 .

사용가능한 Framework Hibernate Ibatis Spring JDBC DAO 패턴

아키텍처 – Domain Model Layer

도메인 모델 데이터베이스의 Entity 와 비슷한 개념을 가지는 것으로 실제 비즈니스 객체를 표시

전 Layer 에 걸쳐 하나의 도메인 모델을 사용함으로서 DTO(Data Transfer Object) 를 만들 필요가 없다 .

여러 계층을 통과하면서 계층들간의 통신시 데이터 전송용 객체 (DTO)를 사용하였을 때 발생할 수 있는 데이터의 유실 가능성 존재