스프링 인 액션 (3판)

 

1장 스프링 속으로

• 스프링 컨테이너 : 객체가 태어나고, 자라고, 소멸한다.
  • 빈팩토리(org.springframework.beans.factory.BeanFactory 인터페이스에 정의됨)
    • DI에 대한 기본적인 지원
  • 애플리케이션 컨텍스트(org.springframework.context.ApplicationContext 인터페이스에 정의됨)
    • 빈팩토리를 확장해 프로퍼티 파일에 텍스트 메시지를 읽고 해당 이벤트 리스너에 대한 애플리케이션 이벤트 발행 같은 애플리케이션 프레임워크 서비스 제공
• 스프링 프레임워크
  • 코어 스프링 컨테이너
    • 빈의 생성, 설정, 그리고 처리 방법을 관리하는 컨테이너.
    • 빈 팩토리와 애플리케이션 컨텍스트가 여기에 포함된다.
    • 모든 스프링의 모듈은 코어 컨테이너 위에 구축된다.
  • AOP 모듈(aspect-oriented programming)
    • 애플리케이션 전체에 걸친 관심사(트랜젝션이나 보안 등)와 객체 간의 결합들을 낮추는데 이용된다.
  • 데이터 액세스와 통합
    • 스프링의 JDBC와 DAO(Data Access Objects) 모듈은 반복되는 코드(컨넥션을 얻어오고, 질의객체를 생성하고, 결과 집합을 처리하고, 컨넥션을 닫는 코드)를 추상화한다.
  • 웹과 리모팅
  • 테스팅
• Bean은 컨테이너가 관리하는 객체이다
  • 객체의 생명주기를 컨테이너가 관리한다.
  • 객체를 싱글턴으로 만들 것인지, 프로토타입으로 만들 것인지

 

2장 빈 와이어링

• DI
  • 애플리케이션 객체 간 결합도를 낮춘다.

 

4장 애스펙트지향 스프링

• 횡단관심사(cross-cutting concerns)
  • 한 애플리케이션의 여러 부분에 걸쳐 있는 기능
  • 보통 애플리케이션의 비즈니스 로직과는 개념적으로 분리된다.
  • 횡단관심사와 이에 영향을 받는 객체 간 결합도를 낮춘다.
• AOP란?
  • 횡단관심사를 애스팩트(aspect)라는 특별한 클래스로 모듈화한다.
    • 전체 코드 기반에 흩어져 있는 관심사항이 하나의 장소로 응집되고,
    • 서비스 모듈이 자신의 주요관심사항(핵심 기능)에 대한 코드만 포함하고 그 외의 관심사항은 모두 애스펙트로 옮겨져서 코드가 깔끔해 진다.
• AOP 용어 정리
  • 어드바이스(advice)
    • 애스펙트가 해야 할 작업
    • ‘무엇’을 ‘언제’ 할지를 정의한다.
    • 즉, 애스펙트가 해야 하는 작업과 언제 그 작업을 수행해야 하는지를 정의한 것이 어드바이스다.
    • 어드바이스가 정의하는 ‘언제’는 작업이 메소드 호출 이전인지 이후인지, 이전/이후 모두인지, 아니면 예외를 던졌을 때만 적용되는지를 의미한다.
      • 이전(before) : 어드바이스 대상 메소드가 호출되기 전에 어드바이스 기능을 수행한다.
      • 이후(after) : 결과에 상관없이 어드바이스 대상 메소드가 완료된 후에 어드바이스 기능을 수행한다.
      • 반환 이후(after-returning) : 어드바이스 대상 메소드가 성공적으로 완료된 후에 어드바이스 기능을 수행한다.
      • 예외발생 이후(after-throwing) : 어드바이스 대상 메소드가 예외를 던진 후에 어드바이스 기능을 수행한다.
      • 주위(around) : 어드바이스가 어드바이스 대상 메소드를 감싸서 어드바이스 대상 메소드 호출 전과 후에 몇가지 기능을 제공한다.
  • 조인포인트(join point)
    • 애플리케이션에 어드바이스를 적용할 수 있는 곳. 즉, 애플리케이션 실행에 애스펙트를 끼워 넣을 수 있는 지점(point)를 말한다.
    • 지점은 메소드 호출 지점이나 예외발생, 필드 값 수정 등이 있다.
  • 포인트컷(pointcut)
    • 애스펙트가 어드바이스할 조인포인트의 영역을 좁히는 일을 한다.
    • 애스펙트가 ‘어디서’ 할 지를 정의한다.
    • 어드바이스가 위빙(weaving)돼야 하는 하나 이상의 조인포인트를 정의한다.
  • 애스펙트(aspect)
    • 어드바이스 + 포인트컷
  • 인트로덕션(introduction)
    • 기존 클래스에 코드 변경 없이도 새 메소드나 멤버 변수를 추가하는 기능
    • 예) 어떤 객체의 상태가 언제 마지막으로 변경됐다는 정보를 추가하는 경우
      • 각 클래스마다 해당 정보를 저장하는 대신, Auditable 어드바이스 클래스를 생성하여 setLastModified(Date) 메소드와 이 상태를 저장하는 멤버 변수를 정의한다. 그 다음 인트로덕션을 적용하면 기존 클래스에 소스 코드 변경 없이 새로운 메소드와 멤버 변수를 도입할 수 있다.
  • 위빙(weaving)
    • 타깃 객체에 애스펙트를 적용해서 새로운 프록시 객체를 생성하는 절차
    • 애스펙트는 타깃 객체의 조인포인트로 위빙된다.
    • 위빙은 대상 객체의 생애 중 다음과 같은 몇가지 시점에서 수행될 수 있다.
      • 컴파일 시간(compile time)
      • 클래스로드시간(classload time)
      • 실행시간(runtime) : 애플리케이션 실행 중에 애스펙트가 위빙된다. 보통 타깃 객체에 호출을 위임하는 구조의 프록시 객체를 위빙 중에 AOP 컨테이너가 동적으로 만들어낸다. 스프링 AOP 애스펙트가 위빙되는 방식이다.
• 스프링 AOP 애스팩트
  • 빈을 감싸는 프록시 객체를 실행시간에 생성함으로써 애스펙트가 스프링 관리 빈에 위빙된다. 프록시 객체는 타깃 객체로 위장해서 어드바이스 대상 메소드의 호출을 가로채고, 타깃 객체로 호출을 전달(forward)한다.
  • 애스팩트의 로직은 프록시가 메소드 호출을 가로채고 나서 실행되며, 그 다음에 타깃 빈의 메소드가 호출된다.
  • 스프링 AOP에서는 프록시가 실행시간에 생성되므로 애스펙트를 위빙하기 위한 별도의 컴파일러는 필요치 않다.

 

5장 스프링의 데이터 액세스 철학

• 스프링이 비검사형 unchecked exception 제공
• 템플릿 메소드
• 스프링은 데이터 액세스 절차상에서 고정된 단계와 가변적인 단계를 템플릿(template)과 콜백(callback)이라는 두 가지의 별도 클래스로 분리한다.
  • 템플릿은 프로세스의 고정된 부분을 담당하고, (트랜젝션 제어, 자원 관리 및 예외처리 등)
  • 콜백은 맞춤 데이터 액세스 코드를 처리한다. (질의객체/statement 생성, 파라미터 바인딩, 질의결과 추출과 변환 등)
• 지연로딩(lazy loading) : 객체 구조가 점점 복잡해짐에 따라 종종 관련성 있는 객체 전체를 한 번에 가져오는 것을 원하지 않는 경우가 생긴다. 지연 로딩은 필요로 하는 실제 데이터만 불러올 수 있게 해준다.
• 조기 인출(eager fetching) : 지연 로딩의 반대 개념으로 한 번의 쿼리로 전체 객체 구조를 가져올 수 있게 해 준다. → 데이터베이스와 애플리케이션 사이에서 발생하는 값비싼 왕복 비용을 줄일 수 있다.
• 케스케이딩(cascading) : 데이터베이스 테이블에 변경을 가했을 때 다른 테이블도 동일하게 변경돼야 하는 경우가 있다.

 

6장 트랜젝션 관리

• 트랜젝션(transaction)
  • 모 아니면 도
  • 트랜젝션을 이용하면 여러 개의 작업을 하나의 작업 단위로 묶어서 전체 작업이 다 이뤄지거나, 아니면 하나도 이뤄지지 않게 할 수 있다.
  • 트랜젝션은 소프트웨어에서 데이터나 리소스들의 무결성이 깨지지 않게 하는 중요한 역할을 한다.
• 트랜젝션의 4가지 구성 요소
  • 원자성(Atomic) : 트랜젝션은 여러 개의 액티비티가 하나의 단위작업으로 묶인 것이다. 원자성은 트랜잭션 내의 모든 작업이 일어나거나 하나도 일어나지 않는 것을 보장한다. 트랜잭션 내의 액티비티 중 하나라도 실패한다면 트랜잭션이 실패하고 롤백된다.
  • 무결성(Consistent) : 트랜잭션이 종료되면 시스템은 그 시스템이 모델링한 비즈니스와 무결성의 상태를 유지한다. 데이터는 현실과 부정합을 일으키지 않아야 한다.
  • 격리성(Isolated) : 트랜잭션은 여러 명의 사용자가 동일한 데이터로 작업해도 각 사용자의 작업이 서로 뒤엉키지 않게 해야 한다. 트랜잭션은 동일한 데이터를 동시에 읽거나 쓰지 않도록 격리돼야 한다.
  • 지속성(Durable) : 트랜잭션이 완료되면 시스템에 이상이 생기더라도 트랜잭션의 결과가 영속돼야 한다. 이를 위해서 결과를 데이터베이스나 다른 형태의 영속적인 저장소에 저장해야 한다.
• 트랜젝션 격리 수준(isolation level)
  • 더티 읽기(dirty read) : 더티 읽기 문제는 한 트랜잭션에서 다른 트랜잭션에 의해 변경됐지만 아직 커밋되지는 않은 데이터를 읽게 되는 문제를 말한다. 이 데이터가 커밋되지 않고 롤백되어 버린다면, 첫 번째 트랜잭션에서 읽은 이 데이터는 유효하지 않은 데이터가 된다.
  • 반복할 수 없는 읽기(nonrepeatable read) : 반복할 수 없는 읽기 문제는 트랜잭션이 같은 질의를 두 번 이상 수행할 때 서로 다른 데이터를 얻게 되는 문제를 말한다. 이는 보통 각 질의 수행 사이에 동시 진행 중인 다른 트랜잭션에서 이 데이터를 변경하는 경우에 발생한다.
  • 팬텀 읽기(phantom read) : 팬텀 읽기는 반복할 수 없는 읽기와 유사하지만 차이가 있다. 팬텀 읽기는 어떤 트랜잭션(T1)이 둘 이상의 데이터 행을 읽은 다음, 동시 진행 중인 다른 트랜잭션(T2)이 추가 행을 삽입할 때 발생한다. T1에서 동일한 질의를 다시 수행하면, T1은 이전에는 없던 데이터 행까지 읽게 된다.

 

7장 스프링 MVC를 이용한 웹 애플리케이션 개발

• 파일 업로드 처리
  1. 화면에서 업로드한 파일을 받는다 (폼에 파일 업로드 필드 추가)
  2. 컨트롤러에서 업로드된 파일을 받도록 한다 (업로드 파일 수신)
  3. multipart/form-data 설정 파일 시스템에 파일 저장
• 2번 업로드 파일 수신

@RequestMapping(method=RequestMethod.POST)
public String addSpitterFromForm(@Valid Spitter spitter, BindingResult bindingResult,
								 @RequestParam(value="image", required=false) MultipartFile image) {
if(bindingResult.hasErrors()) {
		return "spitters/edit";
}

spitterService.saveSpitter(spitter);

try {
  if(!image.isEmpty()) {  // 이미지가 존재하면 다음으로 넘어감
		validateImage(image); // 이미지 유효성 검증

		saveImage(spitter.getId() + ".jpg", image); // 이미지 파일 저장
	}
} catch (ImageUploadException e) {
	bindingResult.reject(e.getMessage());
  return "spitters/edit";
}

return "redirect:/spitters/" + spitter.getUsername();
}

• ValidateImage() 메소드는 업로드된 파일이 요구사항을 만족하는지 확인
• jpeg 파일이 맞는지 확인하고 유효성 검증에 실패하면 RuntimeException을 간단히 확장한 ImageUploadException을 발생시킨다.

private void validateImage(MultipartFile image) {
	if(!image.getContentType().equals("image/jpeg")) {
		throw new ImageUploadException("Only JPG images accepted");
	}
}

• 3번 파일 시스템에 파일 저장
  • saveImage()는 webRootPath의 값 기반의 경로를 갖는 java.io.File 객체를 생성한다.
  • File 객체가 준비되면, 아파치 커먼스 IO(Apache Commons IO)의 FileUtils를 이용해 이미지 데이터를 파일에 저장한다.
  • 여기서도 문제가 발생하면 ImageUploadException이 발생한다.
• 파일시스템 관리 문제
  • 파일 저장을 위한 충분한 공간 확보 책임
  • 하드웨어 문제 발생에 대비한 백업 대책
  • 클러스터로 여러 서버에 걸쳐 있는 이미지 파일 동기화 처리

 

 

9장 스프링 시큐리티

• 모든 자바 웹 애플리케이션은 HttpServletRequest로 시작한다. 요청이 웹 애플리케이션에 대한 접근점(access point)이라면, 바로 그 요청이 웹 애플리케이션에 대한 보안이 시작되는 곳이다.
• 서블릿 필터 프록싱
  • 스프링 시큐리티는 다양한 보안을 제공하기 위해 서블릿 필터를 이용한다.
  • 서블릿 필터를 이용하기 위해 애플리케이션의 web.xml 파일에 다양한 <filter>를 선언한다는 뜻이다.
  • 스프링 시큐리티는 일련의 서블릿 필터를 사용해서 스프링 MVC 컨트롤러를 포함해 웹 자원에 대한 접근을 제어할 수 있다. 그리고 애스펙트를 통해 스프링 시큐리티를 이용하여 메소드 호출에 보안을 적용할 수 있다.

 

10장 스프링 통합

• 스프링 부트 리모팅
  • 리모팅(remoting)은 클라이언트 애플리케이션과 서비스 간의 대화다.
  • 원격 메소드 호출(RMI)
• RMI는 자바의 표준 객체 직렬화를 사용하지만 방화벽을 가로질러 사용하기는 어렵다.
• 스프링의 HTTP 호출자(invoker)는 방화벽이 있어도 괜찮고, HTTP를 가로질러 리모팅을 수행하는 동시에 자바의 직렬화를 이용한다.

 

11장 스프링에게 약간의 휴식(REST)을

• REST는 액션 지향이 아니라 리소스 지향이다. 리소스를 식별하고 위치를 나타낸다.
• HTTP 메소드는 안전성(safety)와 멱등(idempotency)이라는 두 가지 특성을 가지고 있다.
  • 메소드가 리소스의 상태를 변경하지 않으면 안전하다고 간주한다.
  • 멱등적은 메소드는 상태를 변경할 수 도 변경하지 않을 수도 있지만, 반복되는 요청이 첫 번째 요청 이후에 발생할 수 있는 어떠한 부작용도 일으키지 않는다.
    • 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질, 즉 서버에 동일한 요청이 반복적으로 일어나더라도 동일한 응답 결과를 가져와야 한다.

 

12장 스프링 메시징

비동기식 메시징

• 어떤 애플리케이션에서 다른 애플리케이션으로 간접적으로 메시지를 보내고 응답은 기다리지 않는 통신 방식

자바 메시지 서비스(Java Message Service, JMS)

• 메시지 중개자(message broker)
• 목적지(destination)
  • 큐(queue)
    • 점 대 점 모델(point to point)
  • 토픽(topic)
    • 발행구독(publish-subscribe)

 

13장 기타 주요사항

설정 외부화

• 프로퍼티 값 설정을 스프링 설정의 밖으로 이동시켜 외부 프로퍼티 파일에 배치하여 애플리케이션을 다시 배포하거나 다시 묶지 않아도 관리될 수 있는 방법
  • 프로퍼티 대치 변수 설정자(property placeholder configurers)
  • 프로퍼티 오버라이더(property overriders)

JNDI(Java Naming and Directory Interface) 객체 와이어링

 

 

 

// TODO

스프링 인 액션 6판 읽기