JPA 활용 1[인프런 김영한님 강의 메모]

JPA 활용 1 / 김영한님 강의 들으면서 메모

JPQL

.setParameter -> 파라미터 세팅
.setFirstResult() -> 어디서부터 결과값을 뽑을건지 -> 페이징
.setMaxResults() -> 어디까지 결과값을 뽑을건지 -> LIMIT

1. @Transactional(readOnly = true)

• 조회하는 경우에 적용하면 좋다. (쓰기에는 적용x)
• 영속성 컨텍스트에서 더티체킹을 안한다던지, db에 따라서 읽기전용 모드?로 리소스를 절약할 수 있다던지의 이점이 있다.

2. 멀티스레드 환경에서 발생하는 동시성 문제

• 서비스 로직에서 중복체크를 하더라도, 정말 동시에 가입하는 경우 동시성문제가 발생할 수 있다.
• 실무에서는 최후의 방어막으로 DB에 중복체크 할 필드를 Unique 제약조건으로 잡아주는 것을 추천(필수)합니다.

3. 기본적으로 Transaction은 테스트가 끝나면 db를 rollback을 해버린다.

• @Rollback(false)를 달아주면 db에서도 확인해볼 수 있다.(롤백을 못하게 막음)

4. entity가 가지고 있는 값에 대해서는 entity 내부에 비즈니스 로직을 추가하는 것이 객체지향적인 관점에서 좋다. [응집력이 있다]
   -> 같은 맥락에서 validate method도 엔티티에 두는 것. (역할과 책임!)

5. cascade 범위에 대한 고민

• 라이프 사이클을 동일하게 관리하고, 다른 곳에서 참조할 경우가 없는 경우에는 걸어도 된다.

6. 도메인 모델 패턴과 트랜잭션 스크립트 패턴
   도메인모델패턴: 비즈니스 로직 대부분이 엔티티에 있는 것.
   트랜잭션스크립트패턴: 비즈니스 로직이 서비스 계층에 대부분 있는 것.

7. DTO를 써야하는 이유

• DTO 없이 엔티티로 모든걸 하다보면, 엔티티 내부에 화면 종속적인 기능들이 자꾸 추가가 된다.

  (화면 기능때문에 엔티티가 지저분해짐) -> 유지보수가 어려워짐.

• 엔티티를 최대한 순수하게 유지하고, 핵심 로직에만 dependency가 있도록 설계해야한다.

  특히나 API를 만들 때는 절! 대! 엔티티를 반환해서는 안된다.

• API라는 것은 스펙이다 / 만약 엔티티를 반환해주게 되면, 엔티티 수정시 API 스펙이 변해버리게 되는 문제가 발생한다. (+엔티티 중에 원하지 않는 정보까지도 다 노출 된다는 문제점도 있다.)

8. 컨트롤러 단에서 ID 값을 넘겨주는 방식 / 객체를 넘겨주는 방식의 차이

• id를 넘겨준 뒤 서비스단에서 findBy로 객체를 가져오면 그 객체는 영속성 컨텍스트에 담겨진다. (트랜잭션 안에서 관리된다.)
• 그러나 컨트롤러 단에서 객체를 찾고 서비스단에 넘겨주게 되면, 그 객체는 트랜잭션이 모르는 객체(영속성 컨텍스트에 없는 객체)이므로 값을 변경해서 더티체킹을 해주지 않는다.

Ref
[Spring Boot 슬라이스 테스트]

[노마드코더 - 세션 vs 토큰 vs 쿠키? 기초개념 잡아드림. 10분 순삭!]

• MSA 구축? 그게 뭐지...
  -> [오늘의집 MSA 시작스토리]