오늘 학습한 내용

Q. @RequestBody를 통해서 JSON 형식의 Http Request Body를 직접 정의한 RequestDto 객체에 자동으로 매핑하기 위해 필요한 Lombok Annotation은?

• @Getter만 있으면 가능

  → 눈에 보이지 않는 기본 생성자 + 필드 직접 주입(Reflection)

• @Setter만 있어도 가능

  → 눈에 보이지 않는 기본 생성자 + Setter 메서드 조합으로 동작합니다. (고전적인 방식)

• @AllArgsConstructor만 있어도 가능

  → Jackson이 모든 필드를 받는 생성자를 찾아서 JSON의 필드 이름과 매칭해 생성자 파라미터에 값을 넣어 인스턴스 생성

• @NoArgsConstructor만 있으면 불가능

  → 객체를 생성할 방법(@NoArgsConstructor)은 있지만, 그 안의 필드에 값을 채워 넣을 방법(Setter나 다른 생성자)이 없음. 빈 객체만 만들어지고 필드는 모두 null이 된다.

Q. Spring Data Jpa에서 제공하는 Interface JpaRepository<T, ID>의 제네릭 타입의 의미

• T: 해당 JpaRepository가 다룰 Entity클래스

• ID: T에서 정의한 Entity클래스에서 사용하는 PK 필드의 데이터 타입

  Entity: Schedule.class
  Schedule.class의 PK 필드: Long id
  
  implements JpaRepository<Schedule, Long>
  

Q. Repository, Service, Controller 각 레이어의 메소드 네이밍 컨벤션은?

1. Repository
   • 데이터베이스에 직접 접근하여 데이터를 어떻게 처리할 것인지에 초점을 둠.
   • Spring Data JPA의 규칙을 따르는 것이 중요.
2. Service
   • 실질적인 비즈니스 로직을 수행. 주로 비즈니스 로직을 나타내는 동사+도메인 구조
   • 컨트롤러보다 구체적이고 서술적인 이름을 사용.
3. Controller
   • HTTP를 통해 사용자의 요청을 직접 처리.
   • 주로 HTTP 메서드와 매핑되는 동사 등으로 간결하게 표현.

Q. requestDto를 이용하여 Entity 객체를 생성하는 것은 Controller의 책임인가? Service의 책임인가?

• 비즈니스 로직을 담당하는 Service의 책임
  • Entity는 도메인 내부 개념이며 외부 요청/응답과 결합되어선 안 됨.
  1. 비즈니스 로직과 데이터 모델의 결합: DTO에서 엔티티로 변환하는 과정에서 비즈니스 로직을 포함할 수 있음. 변환 로직이 많이 복잡하다면 별도의 Converter나 Mapper클래스를 사용.
     • eg. 특정 필드 값에 따라 다른 필드 값을 설정하거나, 여러 DTO 필드를 조합하여 엔티티 필드를 구성
  2. 재사용성: 만약 여러 Controller가 동일한 Service 메서드를 호출하여 엔티티를 생성해야 한다면, 변환 로직이 Service에 있으면 재사용성을 높일 수 있음.
  3. 테스트 용이성: 비즈니스 로직과 데이터 변환 로직이 Service 계층에 응집되어 있으면 Service의 테스트 코드를 작성하기 용이해짐. 덩달아 Controller의 테스트 코드 작성도 용이해짐.

더 알아볼 내용 / 다음에 할 내용

• Reflection의 개념과 Java의 Reflection API
• ObjectMapper를 이용한 JSON 직렬화, 역직렬화