일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- Eclipse
- JPA
- R프로그래밍
- 머신러닝
- LIKE검색
- 프로그래머스
- 자바
- Rstudio
- cor()
- git
- programmers
- 한글깨지는문제
- core.autocrlf
- 머신러닝프로세스
- RProgramming
- 이중배열
- DTO사용이유
- Q타입클래스
- querydsl적용하기
- queryDSL
- 알고리즘
- java
- str()
- summary()
- stepfilter
- git오류
- R명령어
- 이클립스
- r
- Spring
- Today
- Total
놀고 싶어요
[JPA] Entity보다 DTO 조회를 권장하는 이유 본문
우리는 자바 웹 어플리케이션을 개발할 때 컨트롤러에서 요청과 응답으로 엔티티를 직접 사용하는 경우가 있습니다. 하지만 엔티티를 사용하는 것보다는 DTO 사용을 권장하고 있는데요. 왜 DTO 사용을 권장할까요?
1. 엔티티 내부 구현을 캡슐화할 수 있다.
엔티티가 setter를 갖게 된다면 비즈니스 로직과 상관없는 곳에서도 자원 속성을 실수로라도 변경할 수 있습니다. 만약 그렇게 되면 개발자의 경우에는 어디서 이 값이 변경되었는지 찾아봐야 하는 범위가 커지죠! (컨트롤러도 봐야 되고 서비스도 봐야 되고..)
또한 엔티티를 응답에 노출하게 되면 테이블 설계를 모두 공개하게 되어 보안상으로도 바람직하지 못합니다.
2. 화면에 필요한 데이터만 보여줄 수 있다.
서비스가 커지면 엔티티의 크기도 점차 커집니다. 화면도 다양해지고 API도 더 많아집니다. 따라서 요청과 응답으로 엔티티를 사용하게 되면 해당 화면에서 필요 없는 속성까지도 함께 주고 받게 됩니다. 모든 요청과 응답에 엔티티 모든 속성이 함께 전송되기 때문에 당연히 속도도 느려지게 됩니다.
3. validation 코드와 모델링 코드를 분리할 수 있다.
엔티티 클래스는 데이터베이스의 테이블과 매칭되는 모든 필드가 속성으로 선언되어 있으며, 이미 여러 annotation이 사용되고 있습니다. (@Column, @JoinColumn, @ManyToOne, @OneToOne 등)
여기에 만약 validation 체크하는 @NotNull, @NotEmpty 등과 같은 코드가 들어가게 된다면 엔티티 클래스는 더 복잡해지고 가독성이 떨어집니다. 각각 요청에 필요한 validation을 DTO에 선언한 다면 엔티티 클래스를 좀 더 모델링과 비즈니스 로직에 집중되도록 만들 수 있습니다.
'JPA' 카테고리의 다른 글
[Querydsl] VSCode에서 Querydsl 사용 시, Q타입 import 빨간 줄 해결 방법 (0) | 2022.05.15 |
---|---|
[Querydsl] Querydsl에서 Q타입 클래스 사용하는 방법, 3 가지 (0) | 2022.05.15 |
Spring Boot Data Jpa 프로젝트에서 Querydsl 적용하기 (0) | 2022.05.15 |