[스터디] 배워서 바로 쓰는 스프링 프레임워크

스터디 시작 : 2020년 7월 23일, 중간 중간 스터디 과정에 대해 내용 업데이트 예정

Springboot을 사용하는 회사로 이직했다. (입사 3개월 차ㅎㅎ)

자바도 까먹은 지 오래이고, 웹 개발도 처음이라 제로 베이스로 시작하는 것과 다름이 없어서 공부가 시급했다.

입사하자마자 작은 프로젝트에 투입되었기 때문에 당장 개발을 위해 실무에 적합한 도서인 "스프링 부트와 AWS로 혼자 구현하는 웹 서비스"를 읽었다. 근무 시간에는 Spring boot 프로젝트를 하고, 퇴근 후에는 책을 봤다. (이 책은 당장 실무에 투입되어야 하는 분께 추천한다.)

실무형 책도 도움이 많이 되었지만 두 달 정도 기본적인 CRUD를 개발하고 나니, 정석대로 이론 공부가 필요하다고 판단되었다. 어떤 기능을 추가하거나 조작하려고 할 때도 spring 친구를 만나서 버벅거릴 때가 많았다. 그래서 회사에 동료 개발자 분과 Spring Framework 스터디를 시작하기로 했다.

어떤 책으로 spring 스터디를 할 지 고민되었다. 토비의 스프링도 워낙 유명해서 괜찮을 것도 같았다. 하지만 동료 개발자분께서 한빛 미디어에서 나온 책을 이미 보유하고 계셨고, 목차를 훑어보니 알고 싶어했던 내용들이 알차게 들어있었기 때문에 해당 책을 선택했다.

결론만 말하자면 이 책은 비추이다. => https://prohannah.tistory.com/94

[스터디 운영 방침]

1. 매주 정해진 분량을 공부 후, 흥미로웠던 내용에 대해 자세히 조사하여 발표

2. 탄력적으로 조정

---

[스터디 내용 기록]

2020/08/07 - 챕터 4, 5장 후기

빈 생성 직후 빈 후처리기(BeanPostProcessor)로 초기화 직전에 커스텀 작업을 할 수 있다는 걸 알게 됐다. 아래 그림은 IoC와 AOP를 도식화한 건데, 아직도 잘 모르긴하는데 이제는 조금 추측이 가능해졌따.

• 내가 직접 Bean의 Proxy 객체를 만들지 않아도 되는 이유 : 빈 후처리기들 중에서 프록시를 자동으로 생성함
  1. Spring은 Bean을 생성할 때 마다 후처리기에 전달한다. (DefaultAdvisorProxyCreator가 빈후처리기로 등록되어 있다면)
  2. 빈 후처리기는 전달받은 빈들이 Proxy 대상인지 확인한다.
  3. Proxy 적용 대상이면 Spring 프록시 생성기를 통해 Bean에 대한 Proxy 생성하고 어드바이스를 연결한다. ( 아마 여기서 @Transactaional, @Cachable 등의 내장 AOP 기능을 연결하는 듯? 추측)
  4. 프록시가 생성되면 전달받은 Bean 대신에 프록시 객체를 스프링 컨테이너에게 돌려준다.
  5. 컨테이너는 빈 후처리기가 돌려준 Proxy 객체를 빈으로 등록한다.

Bean이 생성되고, 그 Bean이 AOP기능을 사용중이라면 그 Bean에 대한 Proxy 객체가 생성된 후, 해당 Proxy 객체에 대해서 @Transactional에 대한 작업, @Cachable에 대한 작업을 하는

5장

application.properties 라는 text파일을 이용해서 springboot의 configuration 설정파일에 어떻게 셋팅하는지?를 엿볼 수 있었던 것 같다.

---

2020/08/16 - 챕터 6 (어노테이션기반 개발)

어노테이션으로 Bean 생성 및 의존관계 주입

[어노테이션으로 Bean 생성]

빈 이름 미지정 시 클래스 이름의 첫글자를 소문자로 바꾼 이름으로 지정됨.

스프링의 클래스경로 스캐닝(classpath scanning)을 활성화해서 빈 생성 어노태이션이 설정된 클래스를 자동으로 등록함

1. @Component

2. @Service (@Component로 메타 애너테이션되어 있음)

3. @Controller (@Component로 메타 애너테이션되어 있음)

4. @Repository(@Component로 메타 애너테이션되어 있음)

 

[의존관계 자동 연결]

빈 인스턴스 생성 후 의존관계 주입 어노테이션이 설정된 메서드가 자동으로 호출됨

스프링 4.3부터 빈 클래스에 생성자가 하나인 경우, @Autowired를 설정할 필요 없음 (스프링 컨테이너는 디폴트로 유일한 생성자에 대한 자동 연결을 수행함)

@Autowired

@Inject (JSR 330)

 

[지정자를 통한 의존관계 명시적 연결]

@Qualifier

@Named (JSR 330)

@Resource (JSR 250) : 필드와 세터 메서드를 빈 이름으로 자동 연결 지원

 

• 흥미로웠던 부분

타입 지정 컬렉션(Typed Collection)을 통해 지정자와 연관된 모든 빈을 자동으로 연결할 수 있음

...
@Component
public class Services {
    @Autowired
    @Qualifier("service")
    private Set<MyService> services;
    ...
}

이런식으로 JPA가 @Entity나 @Repository가 설정된 클래스 객체들을 생성하지 않을까?

 

커스텀 지정자 애너테이션 만들기 (흥미롭)

@Target({ElementType.FIELD, ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Qualifier // 커스텀 지정 애노테이션
public @interface Transfer {
    BankType bankType();
}

@Component
public class TransferProcessor {
    @Autowired
    @Transfer(bankType = BankType.SAME_BANK)
    private TransferService transferSameBack;

    @Autowired
    @Transfer(bankType = BankType.DIFFERENT_BANK)
    private TransferService transferDifferentBack;

}

 

스프링 객체 검증(Validate)

1. 스프링 Validator 인터페이스 사용
   • supports()
   • validate()

   특징 ⇒ 제약 사항 정보가 validator에 구현됨

2. JSR 380(빈 검증 2.0) 애너테이션 사용
   • 의존 주입 필요(JSR 380 API jar, 하이버네이트 검증기 프레임워크)

스프링의 LocalValidatorFactoryBean 클래스가 스프링 Validator 인터페이스와 JSR 380의 인터페이스(의존성이 존재한다면)를 구현함

 

[흥미로웠던 부분]

• JSR 380 제약 사항이 적용된 클래스나 인터페이스를 상속받으면, 자식에게도 제약사항이 상속된다.

• JSR 380 제약사항을 만족하지 못한 경우 ConstraintViolationException 예외가 발생한다.

  try {
      // JSR 제약사항이 적용된 메서드 호출
      customerRequestService.submitRequest(...);
  } catch (ConstrainViolationException ex) {
      printValidationErrors(ex);
  }

 

이해 안가는 부분

• p254. 스프링 컨테이너는 디폴트로 유일한 빈 생성자에 대해 자동 연결을 수행하므로, 유일 생성자에 대해 @Autowired를 설정할 필요가 없다. => IoC는 대상 클래스가 Bean일 경우에만 유일 생성자를 무조건 실행해주는 건가?