토비의 스프링 3.1 Vol.1 650p ~ 750p 정리

7.6 스프링 3.1의 DI

- 정책과 관례를 이용한 프로그래밍

7.6.1 자바 코드를 이용한 빈 설정

- 테스트 컨텍스트의 변경

@ContextConfiguration - 스프링 테스트가 테스트용 DI 정보를 어디서 가져와야 하는지 지정할 때 사용하는 애노테이션이다.

 

- <context:annotation-config /> 제거

XML의 내용을 TestApplicationContext 내부로 옮기는 작업을 본격적으로 진행해 보자.

 

- <bean>의 전환

- 전용 태그 전환

7.6.2 빈 스캐닝과 자동와이어링

- @Autowired를 이용한 자동와이어링

- @Component를 이용한 자동 빈 등록

7.6.3 컨텍스트 분리와 @Import

- @import

7.6.4 프로파일

- @Profile과 @ActiveProfiles

- 컨테이너의 빈 등록 정보 확인

- 중첩 클래스를 이용한 프로파일 적용

7.6.5 프로퍼티 소스

- @PropertySource

- @PropertySourcesPlaceholderConfigurer

7.6.6 빈 설정의 재사용과 @Enable*

- 빈 설정자

- @Enable* 애노테이션

7.7 정리

- SQL처럼 변경될 수 있는 텍스트로 된 정보는 외부 리소스에 담아두고 가져오게 만들면 편리하다.

- 성격이 다른 코드가 한데 섞여 있는 클래스라면 먼저 인터페이스를 정의해서 코드를 각 인터페이스별로 분리하는 게 좋다.

다른 인터페이스에 속한 기능은 인터페이스를 통해 접근하게 만들고, 간단히 자기참조 빈으로 의존관계를 만들어 검증한다. 검증을 마쳤으면 아예 클래스를 분리해도 좋다.

- 자주 사용되는 의존 오브젝트는 디폴트로 미리 정의해두면 편리하다.

- XML과 오브젝트 매핑은 스프링의 OXM 추상화 기능을 활용한다.

- 특정 의존 오브젝트를 고정시켜 기능을 특화하려면 멤버 클래스로 만드는 것이 편리하다. 기존에 만들어진 기능과 중복되는 부분은 위임을 통해 중복을 제거하는 게 좋다.

- 외부의 파일이나 리소스를 사용하는 코드에서는 스프링의 리소스 추상화와 리소스 로더를 사용한다.

- DI를 의식하면서 코드를 작성하면 객체지향 설계에 도움이 된다.

- DI에는 인터페이스를 사용한다. 인터페이스를 사용하면 인터페이스 분리 원칙을 잘 지키는데도 도움이 된다.

- 클라이언트에 따라서 인터페이스를 분리할 때, 새로운 인터페이스를 만드는 방법과 인터페이스를 상속하는 방법 두 가지를 사용할 수 있다.

- 애플리케이션에 내장하는 DB를 사용할 때는 스프링의 내장형 DB 추상화 기능과 전용 태그를 사용하면 편리하다.

8장. 스프링이란 무엇인가?

8.1 스프링의 정의

자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크

 

- 애플리케이션 프레임워크

- 경량급

- 자바 엔터프라이즈 개발을 편하게

- 오픈소스

8.2 스프링의 목적

8.2.1 엔터프라이즈 개발의 복잡함

- 복잡함의 근본적인 이유

 

1. 기술적인 제약조건과 요구사항이 늘어가기 때문이다.

2. 엔터프라이즈 애플리케이션이 구현해야 할 핵심기능인 비즈니스 로직의 복잡함이 증가하기 때문이다.

 

- 복잡함을 가중시키는 이유

전통적인 자바 엔터프라이즈 개발 기법은 비즈니스 로직의 복잡한 구현 코드와 엔터프라이즈 서비스를 이용하는 기술적인 코드가 자꾸 혼재될 수 밖에 없는 방식이었다.

8.2.2 복잡함을 해결하려는 도전

- 제거될 수 없는 근본적인 복잡함

엔터프라이즈 개발에 나타나는 복잡함의 원인은 제거 대상이 아니다. 대신 그 복잡함을 효과적으로 상대할 수 있는 전략과 기법이 필요하다.

 

- 실패한 해결책: EJB

기술적인 복잡함을 애플리케이션의 핵심 로직에서 분리하는 데 성공하긴 했으나 EJB 환경에서 동작하기 위해 특정 인터페이스를 구현하고, 특정 클래스를 상속하고, 서버에 종속적인 서비스를 통해서만 접근하고 사용이 가능하게 만드는 등의 EJB 개발 방식은 잘못된 선택이었다.

 

- 비침투적인 방식을 통한 효과적인 해결책: 스프링

침투적인 기술 - 어떤 기술을 적용했을 때 그 기술과 관련된 코드나 규약 등이 코드에 등장하는 경우

비침투적인 기술 - 기술의 적용 사실이 코드에 직접 반영되지 않는다.

8.2.3 복잡함을 상대하는 스프링의 전략

- 기술적 복잡함을 상대하는 전략

1. 기술에 대한 접근 방식이 일관성이 없고, 특정 환경에 종속적이다. -> 추상화를 적용하자.

2. 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여서 등장한다 -> AOP를 적용하자.

 

- 비즈니스와 애플리케이션 로직의 복잡함을 상대하는 전략

핵심 로직을 다루는 코드에는 스프링의 흔적조차 찾을 수 없을 만큼 자신을 드러내지 않는다. 다만 뒤에서 비즈니스 로직을 담당하는 오브젝트들에게 적절한 엔터프라이즈 기술 서비스가 제공되도록 은밀히 도와줄 뿐이다.

 

- 핵심도구: 객체지향과 DI

스프링의 모토 - 기본으로 돌아가자, 자바의 기본인 객체지향에 충실한 설계가 가능하도록 하자.

스프링만 잘 공부하면 자바 언어 자체나 객체지향 설계와 개발 실력 따윈 별로 신경 쓰지 않아도 복잡한 엔터프라이즈 시스템 개발을 잘할 수 있을 거라고 생각하면 오산이다.

8.3 POJO 프로그래밍

8.3.1 스프링의 핵심: POJO

스프링의 주요 기술인 IoC/DI, AOP와 PSA는 애플리케이션을 POJO로 개발할 수 있게 해주는 가능기술이라고 불린다.

8.3.2 POJO란 무엇인가?

POJO - Plain Old Java Object의 첫 글자를 따서 만든 약자

8.3.3 POJO의 조건

- 특정 규약에 종속되지 않는다.

- 특정 환경에 종속되지 않는다.

 

진정한 POJO란 객체지향적인 원리에 충실하면서, 환경과 기술에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 오브젝트를 말한다.

8.3.4 POJO의 장점

POJO가 될 수 있는 조건이 그대로 POJO의 장점이 된다.

8.3.5 POJO 프레임워크

스프링 프레임워크와 하이버네이트를 대표적인 POJO 프레임워크로 꼽을 수 있다.

8.4 스프링의 기술

8.4.1 제어의 역전(IoC) / 의존관계 주입(DI)

- DI의 활용 방법

1. 핵심기능의 변경

2. 핵심기능의 동적인 변경

3. 부가기능의 추가

4. 인터페이스의 변경

5. 프록시

6. 템플릿과 콜백

7. 싱글톤과 오브젝트 스코프

8. 테스트

8.4.2 애스펙트 지향 프로그래밍(AOP)

- AOP의 적용 기법

1. 스프링과 같이 다이내믹 프록시를 사용하는 방법이다.

2. 자바 언어의 한계를 넘어서는 언어의 확장을 이용하는 방법이다.

AspectJ

 

- AOP의 적용 단계

1단계: 미리 준비된 AOP 이용

2단계: 전담팀을 통한 정책 AOP 적용

3단계: AOP의 자유로운 이용

8.4.3 포터블 서비스 추상화(PSA)

환경과 세부 기술의 변화에 관계없이 일관된 방식으로 기술에 접근할 수 있게 해주는 PSA