프로젝트 환경설정
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 보고 검증하고 다듬어 써라
회원 도메인 개발
회원 서비스 개발
멤버로 잡히면 영속성 컨텍스트에 올림
중요한것
opensession inview?
스프링 어노테이션이 기능이 많음
readonly
검증구간 문제되는 이유
멀티스레드 등의 이유로 이름을 unique 로 제약해라.
세터 인젝션 = 사실 안좋음
장점은 테스트 코드
단점 런타임에 수정이 가능해서 건드리면 안됨
요즘 대세 생성자 인젝션
문법적으로 생성시 체크가능
생성자가 1개면 @Autowird 알아서 적용해줌
멤버 final 추천
롬복 적용
@AllArgsConstructor
모든 필드 생성자
@RequiredArgsConstructor
final있는 필드만 생성자
스프링 부트 JPA 에서 @Autowired 지원으로
엔티티 매니저도 사용이 가능하다.
상품 도메인 개발
주문 도메인 개발
주문, 주문상품 엔티티 개발
주문 서비스 개발
Id 들만 넘어옴
실제는 배송지 정보
cascade 옵션
오더1, 오더2, 오더3, 오더 이렇게 되야되는데
그걸 오더 로 바꿔줌(내부 전파)
사용처 = 1군데만 사용할때.
다른곳에 연결되있다면 사용하면 안됨.
지금은 주문수, 배송수 가 같아서 가능(사이클이 같다)
리펙토링 할때 써도됨.
롬복이 도움이됨 (생성자)
생성자 막기
코드를 제약하는 방식으로 설계해야 유지보수를 좋은 방향으로 끌어 갈수 있음.
이런식으로 안함
JPA의 강점 = 또 업데이트 쿼리 짜야되.
여러 상품 추가하게 짜면 됨.
다시 설명
엔티티에 서비스로직을 넣는것 = 도메인 모델 패턴
주문 기능 테스트
웹 계층 개발
회원 등록
회원 목록 조회
상품 수정
변경 감지와 병합(merge)
지인짜 중요함
머지의 비밀
한땀한땀 => JPA 한줄
차이가 있다.
리턴값을 반환해줌.
반환값은 그뒤로 계속 영속성 관리됨.
입력 파라미터 값은 쓰지말자.
문제
변경감지는 = 변경된값.
머지 = 모든값 변경. 값이 없으면 null로 업데이트
null 처리를 하다보면 복잡해짐.
그래서 변경 감지를 쓰자
사실 업데이트는 단발성으로 하면 안됨.
set 여러개 -> change 라는 1 행위
= setter 를 쓰지 말자.
항상 변경 감지를 사용하자.
컨트롤러에서 어설프게 엔티티 생성하지마
애매하다 싶으면 서비스에 dto를 하나 만들어
상품 주문
로직을 나누는 이유
단순화 해야 되는이유
트랜잭션도 깔끔하게 작동함(영속성)
없는곳에서 작업하면 감지,영속이 안됨.





