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 Container에서만 테스트가 가능함. 아키텍처가 여전히 복잡함.

아키텍처- Non EJB Architecture 장점 Servlet Engine에서 서비스 가능. - Cheaper License, Easier administration. Application Server, Servlet Engine에 대해 더 좋은 Portability. Simpler Implemenation - POJO business Object, 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의 지원으로 인해 선언적인 Transaction 관리와 같이 EJB에서 지원하던 기능들의 지원이 가능함. Servlet Engine에서 실행이 가능함. Application Server와 Servlet Engine의 Portability 높음. IOC(Inversion of control)을 통한 Business Object의 관리가 용이함. POJO임으로 Testability가 높음. OOP의 제한이 없음. 단점 Remote 분산환경을 지원하지 않음. Web service를 통하여 해결 가능. 현재 Lightwegiht Container에 대한 표준이 없음. EJB 아키텍트와 개발자들에 친숙하지 않음.

아키텍처 – Lightweight Container Architecture의 예 최근 중, 대규모의 웹 애플리케이션 효율적으로 개발 및 유지보수 하기 위하여 계층화(Layering)하는 것이 일반적 보통 이 Layer는 프리젠테이션, 퍼시스턴스, 비즈니스, 도메인 모델(Domain model) Layer 4개로 나눈다. 각 Layer는 완전히 독립적이어야 하며, 일반적으로 각 Layer사이에서는 인터페이스를 통하여 통신한다.(Domain Model의 경우에는 제외)

아키텍처 – 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에서 제공해야 하는 기능 어플리케이션 비즈니스 로직 처리와 비즈니스에 관련된 빈의 적합성 검증 트랜잭션 처리 다른 계층들과 통신하기 위한 인터페이스 제공 비즈니스 레벨에 있는 객체들간의 관계를 관리 프리젠테이션 계층과 퍼시스턴스 계층 사이의 다리 역할을 해 그 둘이 직접 통신하지 않도록 함으로써 어플리케이션에 유연성을 더함. 사용가능한 Framework Spring Pico Container EJB Session Bean

아키텍처 – Persistence Layer 관계형 정보를 빼내어 객체화 시키는 작업. 데이터베이스의 자료를 저장하고, 수정하고, 삭제하는 작업. Persistence Layer에서 넣지 말아야 하는 기능 비즈니스 로직. Persistence Layer는 단지 데이터 접근과 관련된 기능만 제공해야 함. Presentation 로직과 Persistence 로직을 같이 사용하면 안된다. 사용가능한 Framework Hibernate Ibatis Spring JDBC DAO 패턴

아키텍처 – Domain Model Layer 도메인 모델 데이터베이스의 Entity와 비슷한 개념을 가지는 것으로 실제 비즈니스 객체를 표시 전 Layer에 걸쳐 하나의 도메인 모델을 사용함으로서 DTO(Data Transfer Object)를 만들 필요가 없다. 여러 계층을 통과하면서 계층들간의 통신시 데이터 전송용 객체(DTO)를 사용하였을 때 발생할 수 있는 데이터의 유실 가능성 존재