4. 회원 도메인 개발

1. SQL vs JPQL

sql : 테이블을 대상으로 쿼리

jpql : 엔티티를 대상으로 쿼리

 

 

---

2. 트랜잭션, @Transactional(readOnly = "")

 

트랜잭션 : 데이터를 추가, 변경할 때 트랜잭션 안에서 실행되어야 한다.

 

@Transactional

javax : Java EE에서 제공하는 JTA를 사용하여 트랜잭션 관리

spring : DB 트랜잭션을 관리하는 데 사용

 

@Transactional(readOnly = true) defalut = "false"

readOnly : 트랜잭션에 읽기 전용 모드 설정

                   → 성능 최적화, DB 변경 방지

 

*쓰기 작업에서 readOnly = true 로 설정 시, 데이터 수정이 안 된다.

 

 

---

3. 트랜잭션과 영속성 컨텍스트, @Transcational(rollback = "")

 

같은 트랜잭션, 하나의 영속성 컨텍스트

 

같은 트랜잭션 내에서, 즉 하나의 트랜잭션 범위 내에서 같은 기본 키(pk) 값을 가진 엔티티 객체(ex. 동일한 데이터베이스 레코드)가 여러 번 로드되더라도, 이러한 엔티티들은 하나의 영속성 컨텍스트에서 관리됩니다. 이것은 영속성 컨텍스트가 엔티티의 식별자(pk)를 사용하여 엔티티를 고유하게 식별하고 중복 엔티티를 관리하지 않도록 하는 동작입니다.

 

 

 

+. @Transcactional(rollback = "")

 

ㅁ rollbackFor

스프링은 UncheckedException(RuntimeException)과 Error에 대해서 롤백하는 것이 기본 설정이다.

→ checked 예외를 catch로 처리하든 안 하든, 롤백이 기본적으로 되지 않는다.

→ 즉, 모든 예외상황에서 롤백이 되는 것이 아니다.

 

→ 모든 예외에서 대해서 트랜잭션을 롤백하고 싶다면

@Transactional(rollbackFor = {Exception.class})

 

 

ㅁ rollback

테스트케이스에서 사용될 때만 기본 설정값이, rollback = "True" 

(테스트가 끝나면 트랜잭션을 강제로 롤백)

 

 

---

4. DB Column, Unique 제약조건

validateDuplicateName, 실제 운영 단계의 적용을 고려한다면

멀티쓰레드 환경을 고려하여 설계해야 한다.

 

*회원 테이블의 name 컬럼을 유니크 제약 조건으로 잡아두는 게 안전하다.

CREATE TABLE members (
    id INT PRIMARY KEY,
    name VARCHAR(255) UNIQUE,
    -- 다른 열 정의
);

 

 

---

5. 생성자 주입

Setter Injection

   단점 : 객체 생성 후에도 변경 가능하다.

 

Constructor Injection

   장점 : 변경 불가능한 안전한 객체 생성 가능

             final 키워드 추가 시, 컴파일 시점에 오류 체크 가능

 

@AllArgsConstructor

: 모든 필드에 대한 매개변수를 갖는, 생성자 생성

 

@RequiredArgsConstructor

: final 선언 필드만을 대상으로 하는, 생성자 생성

 

 

---

6. @Test(expected = "")

@Test(expected = IllegalStateException.class)

테스트 결과, 위 예외가 기대됨

→ IllegalStateException이 나오면 pass, 아니면 unpass

 

 

---

7. 테스트 환경

테스트케이스를 위한 스프링 환경

테스트는 격리된 환경에서 실행하고, 끝나면 데이터를 초기화하는 것이 좋다.

따라서 운영 환경과 테스트 환경을 다르게 사용하자.

 

datasource 설정이 없으면,

url : In-Memory DB

ddl-auto : create-drop