Spring Framework (스프링 프레임워크)를 이용하여,
개발하기위해 필요한 것은 무엇일까?
기본적으로 알아야 할것은?
등등......
-- Spring Framework
- Refference
1. The Spring Framework - Reference Documentation
Refference Doc : http://static.springsource.org/spring/docs/2.5.x/reference/index.html
API : http://static.springsource.org/spring/docs/2.5.x/api/index.html
- 스프링은 다른 프로젝트에서 개발된 컴포넌트를 조립해서 응집력 있는 애플리케이션의 개발이 가능하도록 도와주는 IoC 컨테이너이며,
다른 말로 경량급 컨테이너(Lightweight Container)라고도 한다.
IoC 컨테이너의 또 다른 종류로는 PicoContainer와 아파치의 아발론, 그리고 HiveMind 등이 있다.
- Spring Framework를 구성하는 7개의 모듈
1. 코어 컨테이너(core container)
: Spring 프레임웍의 핵심 기능을 제공한다.
코어 컨테이너의 주요 컴포넌트는 BeanFactory(Factory 패턴의 구현)이다.
BeanFactory는 Inversion of Control (IOC) 패턴을 사용하여 애플리케이션의 설정 및 의존성 스팩을 실제 애플리케이션 코드에서 분리시킨다.
2. Spring 컨텍스트(Spring context)
: Spring 프레임웍에 컨텍스트 정보를 제공하는 설정 파일이다.
Spring 컨텍스트에는 JNDI, EJB, 국제화, 밸리데이션, 스케줄링 같은 엔터프라이즈 서비스들이 포함된다.
3. Spring AOP 모듈(Spring AOP)
: 설정 관리 기능을 통해 aspect 지향 프로그래밍 기능을 Spring 프레임웍과 직접 통합시킨다.
따라서 Spring 프레임웍에서 관리되는 모든 객체에서 AOP가 가능하다.
Spring AOP 모듈은 Spring 기반 애플리케이션에서 객체에 트랜잭션 관리 서비스를 제공한다.
Spring AOP에서는 EJB 컴포넌트에 의존하지 않고도 선언적 트랜잭션 관리를 애플리케이션과 결합할 수 있다.
4. Spring DAO
: Spring JDBC DAO 추상 레이어는 다른 데이터베이스 벤더들의 예외 핸들링과 오류 메시지를 관리하는 중요한 예외 계층을 제공한다.
이 예외 계층은 오류 핸들링을 간소화하고, 예외 코드의 양도 줄여준다.
Spring DAO의 JDBC 예외는 일반 DAO 예외 계층에 순응한다.
5. Spring ORM
: 프레임웍은 여러 ORM 프레임웍에 플러그인 되어,
Object Relational 툴 (JDO, Hibernate, iBatis SQL Map)을 제공한다.
이 모든 것은 Spring의 일반 트랜잭션과 DAO 예외 계층에 순응한다.
6. Spring Web module
: 웹 컨텍스트 모듈은 애플리케이션 컨텍스트 모듈의 상단에 구현되어, 웹 기반 애플리케이션에 컨텍스트를 제공한다.
Spring 프레임웍은 Jakarta Struts와의 통합을 지원한다.
웹 모듈은 다중 요청을 핸들링하고, 요청 매개변수를 도메인 객체로 바인딩하는 작업을 수월하게 한다.
7. Spring MVC framework
: MVC 프레임웍은 완전한 기능을 갖춘 MVC 구현이다.
MVC 프레임웍은 전략 인터페이스를 통해 설정할 수 있으며,
JSP, Velocity, Tiles, iText, POI 같은 다양한 뷰 기술을 허용한다.
- IOC(Inversion of Control) 개념 및 프로그래밍 방식
: 객체에 대한 생성 및 생명주기를 관리할 수 있는 기능을 개발자가 아닌 컨테이너가 제공 .
라이프 사이클을 application-context.xml 파일에 등록하기만 함으로 간단하게 제어 할수 있다.
스프링은 자바 빈 규칙을 이용한 Setter Injection을 주로 사용한다.
- DI(Dependency Injection)
: 설정 파일을 통해서 객체 간의 의존 관계를 설정.
객체는 직접 의존하고 있는 객체를 생성하거나 검색할 필요가 없음.
1. 정의
: Spring 프레임워크에서 지원하는 IoC의 한형태
객체 사이의 의존 관계를 객체 자신이 아닌 외부의 조립기(assembler)가 수행
2. 장점
: 일반적인 웹어플리케이션의 경우 클라이언트의 요청을 받아주는 컨트롤러 객체,
비지니스 로직을 수행하는 서비스 객체, 데이터에 접근을 수행하는 DAO객체 등으로 구성됨 .
코드에 직접 의존 객체를 명시하는 경우는 의존하는 클래스가 변경되는 경우 코드를 변경해야 하는 문제가 있다.
DI패턴을 이용하면 의존관계를 객체가 아닌 외부 조립기(assembler)가 설정해 주므로
ServiceImpl클래스의 코드는 Dao객체를 생성하거나 검색하기 위한 코드가 포함되어 있지 않다.
대신 조립기의 역할을 하는 Assembler가 Dao객체를 생성한 뒤 ServiceImpl객체에 전달해 주게 됨.
따라서 객체간의 결합도가 감소
- AOP(Aspect-oriented programming) 개념 및 프로그래밍 방식
: 트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통으로 필요로 하지만,
실제 모듈의 핵심은 아닌 기능들을 분리해서 각 모듈에 적용가능
1. 정의
: 시스템내의 관심사를 분리하는 프로그래밍 기법.
여러 컴포넌트에 중복적으로 나타나야 하는 기능(관심사)은 코드의 중복과 핵심 기능 이외의 코드가 삽입되므로 복잡성이 증가한다는 단점을 가지고 있다 .
이러한 단점을 없애기 위하여 생김
2. 적용
: 공통으로 사용하는 기능들을 모듈화하고 해당 기능을 프로그램 코드에서 직접 명시하지 않고,
선언적으로 처리하여 필요한 컴포넌트에 계층적으로 다양한 기능들을 적용
3. 동작원리
: AOP는 핵심관점과 횡단관점을 분리시키는 것이며,
핵심관심모듈의 중간중간에 횡단관심모듈을 찾는 코드를 직접 넣지 않고,
선언에 의해서 횡단관심모듈이 필요한 지점에 알아서 엮이도록 만드는 것.
핵심관심모듈에서는 횡단관심모듈이 무엇인지 조차 인식할 필요가 없음.
- 핵심관점
: 해당 시스템의 가치와 목적이 그대로 드러나는 관점
기존의 객체지향 분석설계를 통해 쉽게 모듈화/추상화가 가능
대부분의 Business Logic
- 횡단관점
: 핵심관점의 구현에 추가되는 부가적인 관점
모듈화나 추상화가 어려운 관점
모듈로 만드는것이 어려운 것이 아니라 모듈화해서 핵심관점과의 연결이 어렵다.
Logging, Security, Transaction, Error Handle....
4. AOP 구성요소
- 조인포인트
: 횡단관심모듈은 코드의 아무라인에나 삽입이 되는건 아니고 조인포인트라 불리는 특정 위치에서만 삽입이 가능하다.
이러한 위치로는
메소드가 호출되거나 리턴되는 시점,
필드를 엑세스 하는 시점,
객체가 생성되는 시점,
예외가 던져지는 시점,
예외 핸들러가 동작하는 시점,
클래스가 초기화되는 시점
등이다.
- 포인트 컷(언제)
: 어느 조인포인트에 횡단관심모듈을 삽입할지를 결정하는 기능
- 어드바이스 또는 인터셉터(무엇을)
: 횡단관심모듈
- 위빙 또는 크로스커팅
: 포인트 컷에 의해 결정된 조인포인트에 어드바이스를 삽입하는 과정
- 인트로덕션 또는 인터타입 선언
: 기존의 클래스와 인터페이스에 필요한 메소드나 필드를 추가해서 사용할 수 있게 해주는 방법
- 애스팩트 또는 어드바이저(언제 무엇을 할것인가?)
: 포인트 컷과 어드바이스를 합쳐놓은 것. 즉 어디서 무엇을 할지를 나타냄.
- ORM 개념
: Object-Relational Mapping(이하 ORM)은 object와 relational modeling 구현물 사이,
그리고 이 구현물을 서포트하는 시스템간의 변환 프로세스입니다.
조금 더 쉽게 설명하자면 객체와 테이블, 시스템(RDBMSs)을 변형 및 연결해주는 작업이라 말 할 수 있습니다.
ORM을 이용한 개발은 객체와 데이터베이스의 변형에 유연하게 대처할 수 있도록 해줍니다.
- POJO(Plain Old Java Object) 개념
: POJO는 Plain Old Java Object의 약어입니다.
이 개념은 프레임워크 의존적인 코드가 가급적 원래 코드에 끼어들지 않도록 하는 것을 강조합니다.
객체가 전혀 어떤 특별한 존재가 아니라 그냥 일반적인 자바 객체라는 것을 강조하는데 사용하는 이름.
Martin Fowler와 Rebecca Parsons, Josh Mackenzie가 2000년 9월에 이 용어를 만들어내면서 이렇게 말했습니다.
"우리는 왜 사람들이 시스템에서 일반적인 객체를 사용하지 않는지 궁금했는데,
그 이유가 부르기 좋은 이름이 없는데 있다고 결론내렸다.
그래서 POJO라는 용어를 만들었는데 아주 잘 먹혔다."
: VO - Value Object.
테이블에 매핑되는 레퍼 클래스로서 값을 표현하는 객체로서 고유의 identity를 갖지 않는것을 말한다. 그리고 속성에 따라 정의된 객체이고 pass by value로 넘겨지게 되므로 원격 호출이 아닌 로컬 호출이 된다.
PO - Persistence Object.
database identity를 포함하고 있는 객체, 캐싱됨.
BO - Business Object
Data source에 접근하여 데이트를 얻거나 저장하는 것을 목표로하고 비즈니스 로직을 포함하고 있는 객체이다.
Business Object는 Session Bean, Entity Bean 또는 별도의 Java Object로 구현된다.
TO - Transfer Object
Client가 사용하기 위해 데이터 전송에 사용될 조합된 객체. Value Object와 유사함.
POJO - Plain Ordinary Java Object
원격 콤포넌트가 아닌 로컬 Object이고 더이상 EJB 콘테이너에 의존하지 않고 콘테이너 외부에서 단위 테스트가 가능하고 DTO(Data Transfer Object)로도 사용 가능한 것이라고 할까요.
: 필수요소
light-weight (possibly)
flexible
simple
supported by separate optional components such as Hibernate or Spring