강의

멘토링

커뮤니티

프로젝트 환경설정

프로젝트 생성

세팅 완료

플러그인 롬목 = 이미 내장됨

롬복 설정

성능 설정

라이브러리 살펴보기

명령어
./gradlew dependencies 

IDE 에서 보기

View 환경 설정

리턴값 : 화면 이름

정적 페이지

핫리로드 설명중

개발툴 내장 라이브러리 : 

설정 적용 안될시 조치:

파일 적용 방법 : 

JPA와 DB 설정, 동작확인

모든 로그는 로거를 통해서 찍어야됨:

저 설정은 system.out 으로 출력 됨

원칙 : 커맨드와 쿼리를 분리해라
member를 리턴 시키면 사이드 이펙트가 있을수 있음.

그러나 ID 있으면 다시 조회 가능하니 이렇게함

테스트 단축키:

변수 추출 기능:

라이브러리

;MVCC 지우면 오류 해결

DB 로그 : 

데이터가 없는 이유 : 
테스트에 트랜잭션 어노테이션은 디비를 롤백 해줘서 
테스트 데이터를 지워줌
눈으로 보고 싶다면

테스트 단축키: 

파인드와 미리 구한 맴버의 일치 :

영속성 관련 배우면 알게됨

빌드 : 

(꿀팁) 쿼리파라미터 남기기


쿼리 파라미터

(꿀팁) 쿼리파라미터 남기기 - 외부 라이브러리
https://github.com/gavlyukovskiy/spring-boot-data-source-decorator

그래들 리프레시

출력값 : 

현업에서는 꼭 성능 테스트후 적용할지말지 결정

도메인 분석 설계

도메인 모델과 테이블 설계

연관관계 에서 주인이 누군가가 중요하다.

엔티티 클래스 개발1

@Getter 만 항상쓰고 @Setter는 필요한 경우만 쓰자.

@Embeddable @Embedded

외래키가 있는곳을 연관관계의 주인으로 하자.

예를 들어 회원 리스트를 업데이트 했는데 주문 테이블이 통째로 변경됨

mappedBy = "수동적으로 매핑 되는 값" "거울값" "읽기전용" 

엔터프라이즈 버전 JPA 기능

상속관계 맵핑 강의 참조

상속관계 맵핑의 전략(싱글테이블)
싱글 = 다때려박기
조인 = 정규화

테이블퍼 클래스 = 3개의 테이블로 만들기

@Discriminatorcolumn(name="dtype") 상속 관계인데 저장 어떻게 할꺼야 묻는거

@DiscriminatorValue("B") 기본

Enum 타입의 조심해야할점

디폴트가

ORDINAL = 1,2,3,4~~ 중간에 뭐들어가면 망함

그래서

STRING 으로 써야 중간에 값을 넣을수 있음.(장애남)

@OneToOne은 근심과 걱정이 있다.
외래키가 양쪽에 가능 강사의 취향은 Access를 많이 하는곳
주문을 보고 배송을 찾는것이 일반적이지 배송으로 주문을 찾지 않기 때문에 그렇게 함

엔티티 클래스 개발2

부모 자식 관계를 할수 있다 보여주려고 넣음

자기자신을 맵핑하는 케이스를 보여주기 위해서 넣음

@JoinTable(name="category_item")
다대다는 1:다 - 다:1 로 풀어주는 중간 테이블이 필요함

쓰지말아야할 이유
더 추가가 되거나 빼거나 안됨. 그래서 거의 안씀
절대

JPA의 계층구조 (트리 처럼 쭉 내려가는)
요렇게 하시면 됩니다.

JPA는 외래키를 다 잡아줌
꼭 걸어야되야 말아야 되냐

돈 = 정합성이면 필수

아니면 뭐 딱히

중요한 내용

값 타입 = 변경이 되면 안됨

그래서 세팅함수를 구현하고

생성자를 protected로 해야 다른 기술들을 사용할수 있음.

ex.리플렉션, 프록시

생성한거 쓰지말고 DDL 보고 검증하고 다듬어 써라

엔티티 설계시 주의점

장애극복
꿀팁 모든 연관 관계는 지연로딩(LAZY) 으로 설정해야한다.

이걸 조심해야된다
OneToOne ManyToOne
기본 패치 전략이 EAGER 라서 부담이 큼

파일에서 검색

생성자 초기화 베스트 프렉티스
Null 문제, 하이버네이트가 자신의 퍼시스턴트 백으로 바꿈
임의로 바뀌면 작동안함.

툴 베어

테이블, 컬럼명 생성 전략

cascade

연관관계 편의 메서드
양방향에서 세팅하기 좋은 코드

회원 도메인 개발

회원 리포지토리 개발

변수 합치기

JPA는 개체를 대상으로 쿼리
SQL은 테이블 대상으로 쿼리

리파지토리 완성 & 기능 설명

회원 서비스 개발

멤버로 잡히면 영속성 컨텍스트에 올림

중요한것

opensession inview?

스프링 어노테이션이 기능이 많음

readonly

검증구간 문제되는 이유
멀티스레드 등의 이유로 이름을 unique 로 제약해라.

세터 인젝션 = 사실 안좋음
장점은 테스트 코드
단점 런타임에 수정이 가능해서 건드리면 안됨

요즘 대세 생성자 인젝션
문법적으로 생성시 체크가능
생성자가 1개면 @Autowird 알아서 적용해줌 
멤버 final 추천

롬복 적용
@AllArgsConstructor 

모든 필드 생성자 
@RequiredArgsConstructor

final있는 필드만 생성자

스프링 부트 JPA 에서 @Autowired 지원으로 

엔티티 매니저도 사용이 가능하다.

회원 기능 테스트

단축키 

insert 문이 없는 이유
persist를 한다해서 insert문이 나간다고 할수 없음.
스프링의 Transactional 은 커밋을 안하고 롤백 시킴

em.flush(); 쿼리 보기

기능 정리

테스트를 디비를 연동해서 안좋음.

그래서 메모리 디비를 탑재해서 해줌

더 놀라운게 있다.
옵션을 지우면 알아서 설정됨.

상품 도메인 개발

상품 엔티티 개발(비즈니스 로직 추가)

데이터를 가진 객체가 비즈니스 로직을 가지는것이 이상적이다.

보통 서비스에서 수량을 가져와서 조작후 다시 결과값을 넣는 방식 그러지말고
핵심 로직을 데이터를 가지는 쪽으로 옮겨 보자.

exception 폴더 추가후 클래스 추가

예외 클래스 오버라이드

상품 리포지토리 개발

ID 값이 없다는것은 새로운 객체
persist
아니면(어디 있던것) = 업데이트

merge

여러건 찾응것은 쿼리(객체)를 작성해야됨

주문 도메인 개발

주문, 주문상품 엔티티 개발

여기가 제일 중요함

this 를 안쓰는 이유 = 알아서 색칠 해줌
로직을 보면서 강조할때만 씀

한번에 주문을 2개 할수도 있으니 2번 캔슬

총가격 = 주문가격 * 주문 수량

스트림, 람다 활용해서 바꾸세요.

쿠폰, 할인 등으로 바뀔수 있으니 따로 가져가야 된다.

내부에서 dto 받고 그럴수도 있고 그게 깔끔할때도 있음.

주문 서비스 개발

Id 들만 넘어옴

실제는 배송지 정보

cascade 옵션 
오더1, 오더2, 오더3, 오더 이렇게 되야되는데
그걸 오더 로 바꿔줌(내부 전파)
사용처 = 1군데만 사용할때. 
다른곳에 연결되있다면 사용하면 안됨.

지금은 주문수, 배송수 가 같아서 가능(사이클이 같다)
리펙토링 할때 써도됨.

롬복이 도움이됨 (생성자)

생성자 막기

코드를 제약하는 방식으로 설계해야 유지보수를 좋은 방향으로 끌어 갈수 있음.

이런식으로 안함

JPA의 강점 = 또 업데이트 쿼리 짜야되.

여러 상품 추가하게 짜면 됨.

다시 설명

엔티티에 서비스로직을 넣는것 = 도메인 모델 패턴

주문 기능 테스트

좋은 테스트는 순수 메소드 단일 테스트

요정도하면 바로 돌림

맴버 함수로 빼기

함수에 변수 추가, 해당 상수값 대체


좀 더 나은 테스트는 removeStock의 자체 단위 테스트

테스트로 가기, 프로덕션 코드로 가기

실무는 더 꼼꼼하게 짜야됨

도메인 모델의 장점 = 하나씩 테스트하기 좋음

주문 검색 기능 개발

JPQL

동적쿼리 = 지옥

1. 무식 jpql 문자열

2.방법 JPA 자바 쿼리 표준

웹 계층 개발

홈 화면과 레이아웃

home.html로 찾아감

@Slf4j 롬복 활용

리로드 설정인듯

정리

최근 파일 단축키

회원 등록

build.gradle  spring-boot-starter-validation  추가 

 

BindingResult

오류가 담겨서 실행됨, 타임리프와 연계 가능

스프링이 해주는것 
result를 폼으로 끍어옮, 그리고 미리 작성된 에러 코드가 작동함

왠만하면 밖에서 깔끔하게 폼을 잡아준은게 났다.

그리고 컨트롤러에서 따로 벨리데이션해라.

회원 목록 조회

데이터를 페이지에 넣을때는 명확하게 해줘도 좋다. 구지 코드를 줄이지 말자.

타임리프에서 ? 의 의미
null이면 더이상 진행하지 않음.

폼 객체 vs 엔티티 객체 를 사용해야되냐
차이가 나기 때문에 결국에는 망함.

그래서 엔티티만을 순수하게 유지하는것이 중요
화면은 폼, dto를 사용해라.

등록할때 폼객체
뿌릴때는 엔티티가 아니라 뿌릴때도 dto를 변환후 출력.

API 설계시 주의점

절대 멤버 엔티티를 외부로 반환하면 안됨. api에 스펙이 변할수 있다. 혹은 비밀번호 같은 맴버가 나갈수도 있다.

상품 수정

엄청 중요합니다.

커맨드 두번 누르면 라인 셀렉트

multiline select 검색

대 <> 소 문자 토글

실무에서 주소 itemId 입력값을 조작해서 넣을수 있음(해킹)

진짜 말하고 싶은거 다음강의

변경 감지와 병합(merge)

지인짜 중요함

머지의 비밀
한땀한땀 => JPA 한줄
차이가 있다.

리턴값을 반환해줌.
반환값은 그뒤로 계속 영속성 관리됨.
입력 파라미터 값은 쓰지말자.

문제
변경감지는 = 변경된값.

머지 = 모든값 변경. 값이 없으면 null로 업데이트

null 처리를 하다보면 복잡해짐.
그래서 변경 감지를 쓰자

사실 업데이트는 단발성으로 하면 안됨.

set 여러개 -> change 라는 1 행위

= setter 를 쓰지 말자.

항상 변경 감지를 사용하자.

컨트롤러에서 어설프게 엔티티 생성하지마

애매하다 싶으면 서비스에 dto를 하나 만들어

상품 주문

로직을 나누는 이유
단순화 해야 되는이유
트랜잭션도 깔끔하게 작동함(영속성)
없는곳에서 작업하면 감지,영속이 안됨.

주문 목록 검색, 취소

단순 조회는 컨트롤러에서 조회하는편임. 얽메이지 마시고 코딩 하셔라

정리