- java EE
- JPA, JSP, EJB (옛날에 사용됨)
- enterprise급의 어플리ㅔ이션은 엄청 큰거임
EJB
-
컨테이너 - framework임
- transaction 관리
- transaction은 rollback을 줌
- 많은 step중 하나라도 실패하면, 작업내용을 처음으로 돌려보냄 → transaction
- 우리 어플리케이션도 transaction은 필수!
- 기업용 어플리에키션은 필수임
- transaction은 rollback을 줌
- 보안처리
- 지금도 터지긴 함.. yes24
- 창과 방패, 거의 대부분에서 창이 더 유리함
- 해커의 공격을 막아내는것도 보안이지만,
- 로그인 → 보안의 첫 단계
- 원격 호출
- 다른 서버와 통신
- 분산 시스템
- 큰 서비스는 서버를 하나만 두지 않음
- transaction 관리
-
한계
- 빌드가 오래 걸림
- 하나를 바꾸면 여러군데 다 바꿔야함
- 객체지향 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 같이 씀
- annotation 기반
-
요즘은 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
- under
- spring - johnny depp
===============
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이 막을 수 있음!!
- 당장은 코틀린 필요없음, 자바 다 끝나고 ㄱ
- 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임
- annotation으로 설정된 메서드가 먼저 수행됨
-
Eager VS Lazy
설정 정보 외부하
- 노출 안되어야할 정보 (in
application.yml
)- url, username, password (pw뿐만이 아니라 다) → credential
- url is for connecting to db → 나중에 악용될 수 있음
- rds (비쌈)에게 악의적으로 커넥션을 유지해서 비용 엄청 들게 할 수 있음
- url is for connecting to db → 나중에 악용될 수 있음
- gitignore 을 할 수 없는게, 다른 협업해야할 맞춤 정보도 포함되어있음
- yml파일을 다른 코드로 불러올 수 있음
- url, username, password (pw뿐만이 아니라 다) → credential
필요성
- API key 무조건 숨겨야함
- 보안이 무조건 1위
- 운영 (prod)
- db에 username, pw같은것들이 포함됨
- 보편적으로 많이 쓰이는 방식
- 참조
- 다양한 방식의 외부 주입
- OS 환경변수에 넣고 참조할 수도 있음 (자주 안씀) - 내 컴터에서만 됌 ㅋㅋㅋ
- 이렇게 하면 intellij 다시 껐다 켜야함
- ide는 처음 킬 때 os의 환경변수를 다 가져옴
- 서비스들: Github secrets, AWS parameter store (클라우드 환경 어딘가에)
- OS 환경변수에 넣고 참조할 수도 있음 (자주 안씀) - 내 컴터에서만 됌 ㅋㅋㅋ
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 사용
- 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
질문, 답변, 꾸준히 기록하기
- 기록은 취업준비, 취업할때 되돌아볼수있음
- 미래의 나의 자산이 됨