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

EJB

  • 컨테이너 - framework임

    • transaction 관리
      • transaction은 rollback을 줌
        • 많은 step중 하나라도 실패하면, 작업내용을 처음으로 돌려보냄 transaction
        • 우리 어플리케이션도 transaction은 필수!
        • 기업용 어플리에키션은 필수임
    • 보안처리
      • 지금도 터지긴 함.. yes24
      • 창과 방패, 거의 대부분에서 창이 더 유리함
      • 해커의 공격을 막아내는것도 보안이지만,
        • 로그인 보안의 첫 단계
    • 원격 호출
      • 다른 서버와 통신
      • 분산 시스템
        • 큰 서비스는 서버를 하나만 두지 않음
  • 한계

    • 빌드가 오래 걸림
    • 하나를 바꾸면 여러군데 다 바꿔야함
    • 객체지향 X 컨테이너 주도 개발
  • 서블릿 - spring 안쓰고 java에서 이거 대신 사용 가능

    • 근데 너무 복잡함
    • spring 코드는 내부적으로 sublet을 씀
    • sublet들을 관리하는 컨테이너가 있음 WAS / sublet container
  • channelService는 ChanepRepository를 의존

    • 결정은 외부에서
    • EJB는 그게 안됨
      • 무조건 구현 클래스

Spring

  • pojo

    • plain old java object?
  • 특정 컨테이너에 종속되어있지 않음

  • Tomcat

  • 애노테이션을 적절히 달아주면 스스로 spring이 판단함

    • 외워야함
  • IoC/DI가 이해하기 젤 어려움

  • 객체 자체를 테스트할 수 있음

    • 테스트코드를 얼마냐 잘짜느냐에 회사갈 수 있을지 판정날수 있음
    • QA랑은 좀 다른데, 테스트를 전반적으로 담당
    • 하지만 1차적인 검증은 개발자가 해야하고, 테스트코드는 필수다
  • annotation

    • @Transactional annotation만 붙히기
    • 엄청 편리함
    • 하지만 제약조건도 존재함, self invocation 등
  • SRP

    • 책임 = 변화의 이유
    • A를 수정하면 B도 같이 수정됨
      • A,B 책임을 나눠가짐
      • B가 책임을 A것도 같이 가지고 있음
      • 이 케이스는 낮은 응집도
    • 높은 응집도, 낮은 결합도
      • 이걸 잘 지키면 SRP는 자동으로 따라옴
    • layered architecture
      • 역할에 따라서 책임 분리
      • controller
        • 요청을 받고 응답처리
        • service만 의존 (repository를 의존 X)
        • service가 어떻게 코드를 짰던 내 책임이 아님
      • service
        • 핵심 비즈니스 로직
        • repository에 의존
      • repository
        • 저장 로직
      • 생성자가 파라미터가 많은 클래스는 srp위반일 가능성이 크다
  • SoC

    • 관심사의 분리 조금 더 넓은 단위의 책임
    • ApplicationContext
      • spring의 핵심기능포함

TDD

  • TDD, DDD, EDD

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

    • 지금까지 만들었던 기능들을 짜볼까 test code
    • test code가 끝나면 다음 개발 일로 넘어감
    • 테스트를 먼저 짬, 이 테스트를 통과할 수 있는 기능을 만드는것
  • 깊에가면 너무 어려움… 실무에도 적용하면 어려움 (모든 구성원은 tdd에 대한지식이 높아야함)

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

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

    • 통합된 환경에서 모든 기능이 잘 동작하느냐
    • @springboottest
      • 컨테이너를 로딩?
  • spring은 처음부터 테스트가 가능한 코드를 중심에 두고 설계됨

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

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

Spring 핵심 개념

  • 가장 어렵고, 중요한 부분

IoC

  • 제어권은 외부 시스템/컨테이너 (EJB)
    • spring이 제어권을 가짐
  • IoC
    • 생성자에 주입됨!!

IoC 컨테이너

  • IoC를 구현한 구체적인framework

    • 객체의 생성, 초기화, 의존성처리등 BeanFactory의 직업
    • BeanFactory ApplicationContext
      • BeanFactory - 요즘은 개발자가 이걸 만지는 일은 거의 없음
  • Bean은 spring이 관리하는 객체

  • configuration metadata

    • annotation 기반
      • annotation만 달아주면 알아서 정보가 들어감
    • 현실적으로 annotation 기반, java config 같이 씀
  • 요즘은 AnnotationConfigApplicationContext을 씀

IoC > DI > Bean

spring의 기본 scope는 singleton임

우리가 만드는 객체를 어떻게 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

의존성

  • 결정권은 client로 감

    • 나를 쓸 때 뭘 쓸지 결정해줘
    • controller은 (생성자에게) 주입당하고 있음 생성자주입
      • 생성자주입의 장점
        • final을 붙힐 수 있음 > public final menuService
    • controller는 이제 결정하지 않고 수동적으로 시키는것만 쓰게 됨
    • factory pattern
  • 의존성 주입은 왜 필요할까요

    • new 키워드를 쓸지 말지 여부를 결정하는 것
  • 앞으로 특정하 경우가 아니라면 new를 안씀

  • base entity 말고 serializeble 빼기

  • setId빼기 (사용안하고있음)

AOP

  • 자동으로 끼워넣을 때 proxy를 사용
  • weaving - spring aop에서만 쓰이는 표현
  • 꼭 알아야할것
    • aspect
    • join point
    • advice
    • pointcut
  • 꼭 다른 클래스 사용해야함

DispatcherService 프론트 컨트롤러 <<<< 필수로 알아야하긴 함

2 3 티어 아키텍쳐

  • 프론트와 백은 분리되어있음
  • 프론트에서 데이터를 보내면 우리는 못읽음 (형태가 내부적으로 다름)
    • 중간에 클라이언ㅌ, 서버 데이터를 주고받기 위해서 json으로 타입을 변경
    • json이라는 데이터 형태를 통해 주고받음

========

  • spring and springboot
    • spring - johnny depp
      • 뼈대만 있음, 필요한것들을 찾아서 하나하나 버젼을 맞춰줘야함
      • 버젼을 하나라도 틀리면 빌드가 불가능해짐
      • xml 코드 포함
      • 30일정도 소요… 시간이 아까움
    • springboot - jack sparrow
      • xml NO
      • 복잡한 configs NO
      • 컨트롤러에 대한 설정
      • gradle spring과 관련된 라이브러리는 starter이라는 prefix가 있음
        • under dependencies

===============

6.16.25

설정 파일과 프로필

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")
    • 변경하면 바로 재시작 가능

=========

  • 의존성 주입
    • public ProductController ((Product Service productService)
    • 같은 타입의 빈이 있으면 의존성 주입
    • 만약에 같은타입이 여러개면, 이름을 봄 (이름도 같으면 에러던짐)x`

=====

  • 모든 빈은 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으로 등록됨

  • 생성자 2개 이상일때 @Autowired 필요함
    • setter에는 무조건

========================================= 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에있는거 가져오기

  • 필드로 가져오기
  • @Value("${}")
  • :
    • 이 값이 없으면 : 뒤에 있는 걸 대신해서 씀
    • @Value("${my.username:NullName}")
      • null
      • false
  • if u want to add to a list, use .split

계층을 그래도 옮겨올수도 있음!!

  • edited (combine this and the previous)

    • 객체 안에 객체안에 객체
    • 데이터를 원하는 형태로 받아올 수 있음 - 계층형 구조
    • 근데 생각보다 불편함 (굳이 외울필요x)
  • 이거 한번 스스로 타이핑 해보기..

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

    • validation 사용
  • @NotBlank

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

환경설정 객체

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

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

@Profile

  • 어디서든 사용할 수 있음

조건부 구성

  • 잘 안씀 (그냥 학습용으로 이해하고 넘어가기)

bean 초기화 순서

  • repo service > controller

  • 작은 것부터 만듦

  • beannotfoundexception < 노트정리

@DependsOn

  • 직접 포함할 떄 씀. 결합도가 높을 때
  • 의존관계를 미리 알고있어야 함 - 빈의 이름 정확하게 알고있어야함

@Order

  • 낮은 순부터 (번호표라고 생각
  • @Bean만 있는 애들은 못사용함
  • 실행순서만 제어
  • 여러 빈을 받을 떄 순서를 지성해서 컬렉션에 넣을 수 있다
  • 빈이 사용될때

@Ordered

  • @Order랑 똑같은 일을 함

다른데에서 만들어진걸 객체로 만들고 싶을 떄 - Configuration + Beans, 그리고 Ordered

질문, 답변, 꾸준히 기록하기

  • 기록은 취업준비, 취업할때 되돌아볼수있음
  • 미래의 나의 자산이 됨