TIL(34) 21-11-04 : JPA를 이용하여 CRUD 기능 구현

Facts

✅  JPA를 이용하여 데이터베이스 CRUD 기능을 구현
✅  클라이언트 화면 추가

 

 

Findings

✏️  Lombok

Lombok : 자바 프로젝트를 진행하는데 거의 필수적으로 필요한 메소드/생성자 등을 자동생성해줌으로써 코드를 절약할 수 있도록 도와주는 라이브러리

• @Getter : object의 Getter 메소드를 자동으로 생성
• @NoArgsConstructor : parameter가 없는 기본 생성자를 자동으로 생성
• @RequiredArgsConstructor : final이나 @NoNull인 필드값만 paramter로 받는 생성자를 자동으로 생성

 

✏️  DTO

데이터(ex. 객체)를 주고 받을 때, Entity를 사용하는 것이 아니라,
새로운 클래스를 사용하기 위해, DTO가 나왔다.

 

🤔  Why?

1. Entity는 DB와 연결되어있기에, Entity를 response 하면, 오류가 날 가능성이 크기 때문이다.
   
   
2. 또한, Entity를 통해 외부 사용자에게 데이터베이스의 스키마 형태, 데이터베이스의 구조,
   서비스 내부 로직을 유출 될 수 있기 때문이다.
   
   → 유출을 해결하기 위한 방법 : DTO 사용
        DTO는 변수의 접근자를 private로 설정하고
        public한 getter함수를 만들어 캡슐화 할 수 있다.
   
   
3. 화면에 필요한 데이터를 선별할 수 있기 때문이다.
   
   단순히 사용자의 이름만 보여주면 되는 상황에서 요청과 응답으로 Entity를 사용한다면
   필요 이상으로 사용자가 가지고 있는 다른 속성들까지 항상 데이터 전송에 참여하게 된다.
   하지만 특정 API에 필요한 데이터를 포함한 DTO를 별도로 만들면,
   화면에서 요구하는 필요한 데이터들만 선별하여 요청과 응답을 할 수 있는 장점이 있다.
   
   
4. Validation 코드와 모델링 코드를 분리할 수 있다.
   
   Entity 클래스는 DB의 테이블과 매칭되는 필드가 속성으로 선언되어 있고,
   복잡한 비즈니스 로직이 작성되어 있기 때문에
   속성에는 @column과 같은 모델링을 위한 코드가 추가된다.
   
   여기서 만약, @NotNull과 같은 요청에 대한 값의 validation 코드가 들어간다면
   Entity 클래스는 더 복잡해지고 가독성이 저하된다.
   
   각각의 요청에 필요한 validation을 DTO에서 정의한다면,
   Entity 클래스를 좀 더 모델링과 비즈니스 로직에만 집중되도록 만들 수 있다.

 

 

정의

@RequiredArgsConstructor
@Getter
@Setter
public class LectureRequestDto {
    private final String title;
    private final String tutor;
}​

적용

LectureRequestDto requestDto = new LectureRequestDto("Spring과 친해지자!", "죠이");​

 

 

🤔  Entity는 DB와 연결되어 객체를 주고 받는데 사용하면, 오류가 날 가능성이 크다고 했는데,
      어떤 오류가 생길 수 있을까?

• 순환 참조 문제가 발생할 수 있다.
  양방향 참조된 Entity를 Controller에서 response로 return하게 되면,
  Entity가 참조하고 있는 객체는 지연 로딩 되고,
  로딩된 객체는 또 다시 본인이 참조하고 있는 객체를 호출하는 순환 참조의 문제를 낳는다.
  따라서 이를 방지하기 위해 return으로 DTO를 두는 것이 더 안전하다.

 

 

📝  참고 자료

요청과 응답으로 엔티티(Entity) 대신 DTO를 사용하자