leejunkim

Spring notes

9 min read

  • java EE
    • JPA, JSP, EJB (옛날에 사용됨)
    • enterprise급의 어플리ㅔ이션은 엄청 큰거임

Spring

  • SRP
    • 책임 = 변화의 이유
    • A를 수정하면 B도 같이 수정됨
      • A,B 책임을 나눠가짐
      • B가 책임을 A것도 같이 가지고 있음
      • 이 케이스는 낮은 응집도
    • 높은 응집도, 낮은 결합도
      • 이걸 잘 지키면 SRP는 자동으로 따라옴
  • SoC
    • 관심사의 분리 → 조금 더 넓은 단위의 책임

TDD

  • TDD, DDD, EDD

  • TDD를 잘 알아야하기 위해 DDD도 잘 알아야함

  • 전

    • 지금까지 만들었던 기능들을 짜볼까 → test code
    • test code가 끝나면 다음 개발 일로 넘어감

  • 후

    • 테스트를 먼저 짬, 이 테스트를 통과할 수 있는 기능을 만드는것

  • 깊에가면 너무 어려움… 실무에도 적용하면 어려움 (모든 구성원은 tdd에 대한지식이 높아야함)

    • 하지만 잘 이용하면 코드 품질이 엄청나게 올라감..!
    • 기능개발을 분리해서 작은 단위로 개발할 수 있음 → 분할정복 가능

  • 단위테스트

    • 아주 작은 규모의 테스트
    • 기능 딱 하나, method 하나
    • Mocking 도구 많이씀
      • Mock up - 가짜 모형

  • 통합 테스트

    • 통합된 환경에서 모든 기능이 잘 동작하느냐
    • @springboottest
      • 컨테이너를 로딩?

  • spring은 처음부터 테스트가 가능한 코드를 중심에 두고 설계됨

    • 다양한 테스트 라이브러리를 내장하고 있음

  • BDD

    • given when then
    • 테스트코드를 잘 설계하기 위한 기법

Spring 핵심 개념

IoC

IoC 컨테이너

  • configuration metadata
    • annotation 기반
      • annotation만 달아주면 알아서 정보가 들어감
    • 현실적으로 annotation 기반, java config 같이 씀
  • 요즘은 AnnotationConfigApplicationContext을 씀
  • 우리가 만드는 객체를 어떻게 bean으로 만들까
    • xml
    • annotation (2가지 명백하게 구분)
      • java config - 설정으로 관리
      • annotation config
    • not all objects should be a bean → only objects that needs to be managed by the IoC container

설정 파일과 프로필

application.properties, application.yaml

  • 하지만 실제 일할때는 더 나뉨
    • 운영환경, 로컬환경
      • 운영환경에 시큐리티, 로깅, AWS 설정은 꼭 있어야 한다.
application.yaml        # 공통 설정
application-dev.yaml    # 개발환경
application-prod.yaml   # 운영환경

어플리케이션 실행 프로세스

  • @Component
    • 클래스 위에만 있음, 클래스는 우리가 작성함
    • 클래스의 인스턴스를 bean으로 등록
  • @Bean
    • return값을 bean으로 등록
    • spring이 이미 만들어진 클래스 (@Component 못붙힘 수정불가라서)를 bean으로 등록하고 싶을 때
    • @Bean is typically used inside a @Configuration class

Starter

  • JPA - 인터페이스
    • 표준 명세
    • JPA는 추상화되어있음
    • JPA + hibernate?

의존성 관리 심화

  • developmentOnly
    • 개발환경전용
    • yml profile에만 적용?<<<<
  • developmentOnly("org.springframework.boot:spring-boot-devtools")
    • 변경하면 바로 재시작 가능

=====

  • 모든 빈은 POJO가능한 객체를 지향함
    • 대부분의 빈은 POJO
  • 빈의 범위를 지정하지 않으면 모든 범위의 디폴트 값은 singleton이다
    • 성능성의 이점을 포기함
    • 하지만 그럼 왜? → 동기화 문제
      • 다른 곳에서 여러번 호출될떄 데이터가 유지됨
  • when does it get destroyed?? (when is destroyMethod callled??) <<이거 알아보기
  • 생성시점: eager
    • lazy로 변경할 수는 있음
    • 우리가 등록한 bean들은 spring이 켜질떄 다 만들어짐

Spring IoC Bean 생명주기

  • 실제 설차는 다이어그램처럼 딱딱 나눠지지 않음
  • 의존관계가 더 적은 객체부터 만들어짐 실제로는 (로우레벨에서는)
  • 의존성 주입 (우리는 생성자만 씀, NPE 피할 수 있음… 자바는 null과의 싸움임..)
    • null과의 싸움을 실제로 kotlin이 막을 수 있음!!
      • 당장은 코틀린 필요없음, 자바 다 끝나고 ㄱ
  • 초기화 - 사용가능한 형태로 만들어주는 것
  • 종료되는 시점에 소멸

자바 기반 빈 설정

  • means configuration
  • includes component and componentscan

@Configuration

  • is a bean because it contains @Component

  • @Bean

    • ApplicationContext가 실제 메서드를 실행함

  • 명시적 표현

    • bean이 다른 bean을 주입

  • 내부에서 singleton을 쓰기 때문에 항상 동일한거 줌

  • bean

    • 이름은 그냥 함수이름으로 됨
    • Component는 클래스명이 빈의 이름으로 됨

lombok

  • download plugin
build gradle

configurations { compileOnly { extendsFrom annotationProcessor } }

annotationProcessor ‘org.projectlombok:lombok’ compileOnly ‘org.projectlombok:lombok’

  • regex (정규식)
    • 편리하긴 하지만 성능/효율이 엄청 떨어짐 (내부에서 재귀호출)

  • 저 Demo2Application도 bean으로 등록됨

========================================= 6.18.25

  • 빈 찾을 때 (순서)
    • type
    • name
    • 여기까지 넘어왔으면 우리가 지정을 해줘야함

bean scope

  • InitializingBean

    • 초기화 이후 수행

  • Disposable bean

    • 소멸 시점에 수행

  • JSR-250

    • 자주 사용하는 것들을 미리 만들어놓은 명세서 같은

  • 1번이 먼저 수행됨

    • annotation으로 설정된 메서드가 먼저 수행됨
      • 여기도 annotation먼저, 그다음에 interface임

  • Eager VS Lazy

설정 정보 외부하

  • 노출 안되어야할 정보 (in application.yml)
    • url, username, password (pw뿐만이 아니라 다) → credential
      • url is for connecting to db → 나중에 악용될 수 있음
        • rds (비쌈)에게 악의적으로 커넥션을 유지해서 비용 엄청 들게 할 수 있음
    • gitignore 을 할 수 없는게, 다른 협업해야할 맞춤 정보도 포함되어있음
    • yml파일을 다른 코드로 불러올 수 있음

필요성

  • API key 무조건 숨겨야함
  • 보안이 무조건 1위
  • 운영 (prod)
    • db에 username, pw같은것들이 포함됨
  • 보편적으로 많이 쓰이는 방식
    • 참조
  • 다양한 방식의 외부 주입
    • OS 환경변수에 넣고 참조할 수도 있음 (자주 안씀) - 내 컴터에서만 됌 ㅋㅋㅋ
      • 이렇게 하면 intellij 다시 껐다 켜야함
      • ide는 처음 킬 때 os의 환경변수를 다 가져옴
    • 서비스들: Github secrets, AWS parameter store (클라우드 환경 어딘가에)

yml에있는거 가져오기

  • build.gradle안에 validation추가 - 유효성 검사

    • validation 사용

  • @NotBlank

    • ""
    • ” ”
    • null (if u only want not null use @NotNull)

환경설정 객체

  • 우리가 가진 실제 환경정보를 가지고 싶을 떄 Environment 객체
    • springboot 기본값 8080 - Tomcat의 기본 보트 (springboot가 아니라.. 그냥 tomcat을 내장해서)

함수형 인터페이스는 바로 람다식 표현 가능 (메서드가 1개밖에 없기떄문에)

bean 초기화 순서

  • repo → service > controller
  • 작은 것부터 만듦

Graph View