실전! 스프링 부트와 JPA 활용1 - 웹 어플리케이션 개발
-
프로젝트 환경설정
-
요구사항 분석
-
도메인과 테이블 설계
-
아키텍처 구성
-
핵심 비즈니스 로직 개발
-
테스트
-
웹 계층 개발
도메인기반설계? 테스트용도로 h2Database를 써보띾?
Thymeleaf
-
마크업을 빼지않고 그래도 사용하는것
-
spring integration됬다는 것에 장점
-
관례상
/templates
에 들어있는 html을 그대로 렌더링햄-
resource:/templates/{name}.html
-
-
순수하게 HTML을 그대로 열어도 열린다. 다른 언어들에는 if, switch등등 문법이 많아서 깨지는게 이것이 있음으로써 가능
-
resource 폴더에 있어서 서버를 다시 띄우야 한다.
-
매번 바꿀때마다 불편하지 않은가.
-
리컴파일해도 안바뀜
-
devtools 받으면 그 파일만 리컴파일하면 반영됨
-
devtools
라이브러리를 넣으면 캐시도 없고 리로딩도 하게 해줌
-
-
정적파일은
resource/static
디렉토리에 저장
H2 Database
-
개발이나 테스트용도로…
-
;MVCC=TRUE
옵션 사용? -
저장시 왜 id를 반환하기
-
command랑 query를 분리하라. 저장하고나면 command성이여서 id정도만 리턴하도록 설계함
-
Editor > Live Template 에 custom에 |
-
@Transactional
이 테스트에 있으면 다 롤백함-
@Rollback(false)
추가하면 안지워짐
-
-
equals
할 떄 어떻게 같아지는지는?-
영속성 트랜잭션안에서는 저장하고 조회하면 똑같게 나옴, id 값이 같으면 같은 entity로. 그래서 select 쿼리도 안날라가고 영속성 컨텍스트에 있는 캐시가 반환.
-
-
query 파라미터가 안나가는데…
-
logging.level.org.hibernate.type: trace
이렇게 주면 출력됨 -
com.github.gavlyukovskiy.spring-boot-data-source-decorator
라이브러리 활용-
p6spy-spring-boot-starter
-
-
도메인 분석 설계
-
요구사항 분석
-
도메인 모델과 테이블 설계
-
엔티티 클래스 개발
-
엔티티 설계시 주의점
-
기능 목록, 유저스토리, …
-
모델링 중요
-
jpa 다:다 관계는 쓰면 안됨
-
양방향보더는 단방향
-
"회원이 주문을 하니까"를 생각해서 회원이 주문을 가진 것이 아니라 ('회원을 통해서 항상 주문이 일어난다’가 아니라) 시스템관점에서 맴버랑 오더랑 동급으로 보고 고민.(주문을 생성할때 회원이 필요하다)
-
실제 쿼리에서도 오더에서 필터링 조건으로 맴버가 들어가는 것이지, 맴버를 조회한 뒤 주문을 조회하는게 아니다.
-
-
싱글 테이블 전략, 단일 테이블 전략
-
엔티티분석과 테이블분석을 구분한듯
-
양방향 관계에서…
-
일대다 관계에서는 무조건 다에 외래키가 존재
-
외래키가 가까운것에 있는걸 연관관계의 주인으로 정하라(원칙?)
외래 키가 있는 곳을 연관관계의 주인으로 정해라.연관관계의 주인은 단순히 외래 키를 누가 관리하냐의 문제이지 비즈니스상 우위에 있다고 주인으로 정하면 안된다.
-
-
실무에서는
@ManyToMany
를 쓰면 안된다.-
중간 테이블에 컬럼을 추가할 수 가 없고 세밀하게 쿼리를 실행하기 어렵기 때문. 한계가 있다.
-
아예 일다대, 다대일 매핑으로 풀어서 사용하자.
-
-
내장 타입에는
@Embedded
or@Embeddedable
-
연관관계의 주인을 정해줘야 할 때
@OneToMany(mappedBy = "컬럼명")
-
어디의 값이 바뀔 때 뭘 믿고 해야하지?
-
foreign key가 가까운곳이 주인으로 잡는게 좋다.
-
-
@Enumerated(EnumType.ORDINAL)
이 default,EnumType.STRING
추천 -
외래키를 꼭 걸어야 하나?
-
시스템마다 다를듯
-
실시간 트래픽 중요하고 정합성보다는 잘 서비스되는게, 유연하게 - 외래키 빼고 인덱스
-
데이터가 중요하고 정합성 - 외래키
-
-
setter를 열면 사이드이펙트가 발생할 수 있으니, setter를 닫고 비지니스 메서드를 제공함
-
테이블은 타입이 없으므로 컬럼명을
id
로만 하는 것은 구분이 어렵다 그래서 테이블은 관례상테이블명+id
를 많이 사용한다.-
memberId
ormember_id
중요한것은 일관성
-
-
값 타입은 이뮤터블하게 하자
-
JPA 스펙상 빈 생성자를 protected 까지 허용
-
-
엔티티 설계시 주의점
-
setter 가급적 노. 유지보수가 어렵다. 충분히 setter 없이 개발 가능
-
모든 연관관계는 지연로딩으로 설정
-
EAGER
즉시로딩은 예측이 어렵고, (맴버 조회할떄 연관된 애들을 모두 조회) -
LAZY
로 설정하자 -
특히 JPQL 실행할 떄 N + 1 문제가 자주 발생한다.
-
fetch join 또는 엔티티 그래프 기능 사용
-
@XToOne
-
-
('도메인 분석 설계 - 엔티티 설계시 주의점' 부터 보기 - 05:57 ~ )