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

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

2. 아키텍처 – 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) 등장

3. 아키텍처 - Classic EJB Architecture • 장점 • 정형화된 Service Layer 제공 • 선언적인 Transaction 관리와 같은 EJB 서비스 제공 • Business Object를 여러 서버에 분산이 가능 • 많은 개발자들이 개발에 익숙한 상태 • 단점 • 실행속도와 개발속도등 여러 부분에서 상당한 overhead가 발생함. • OO(Object Oriented)의 제한된 구현만이 가능함. • 테스트하기 어려움. 항상 EJB Container에서만 테스트가 가능함.

4. 아키텍처 - Local EJB Architecture • 장점 • 분산환경을 제외한 Remote EJB 아키텍처의 모든 강점을 제공 • RemoteException을 처리하지 않아도 됨 • 단점 • Remote 분산환경을 제공하지 않음 • 테스트하기 어려움. 항상 EJB Container에서만 테스트가 가능함. • 아키텍처가 여전히 복잡함.

5. 아키텍처- 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보다 좋을 수 있으나 경우에 따라 다름.

6. 아키텍처 - 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 아키텍트와 개발자들에 친숙하지 않음.

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

8. 아키텍처 – 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 존재

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

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

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