Data Access Object
데이터 베이스의 data에 접근하기 위한 객체.
Database 접근 로직(CRUD)과 Business로직을 구분하기 위해 사용한다.
과거 로우레벨 API 때문에 데이터베이스에 접속해서 데이터베이스와 교류하는지에 더 초점을 기울였고 그 결과 자신이 필요한 인터페이스를 DAO에게 던지고 DAO는 이 인터페이스를 구현한 객체를 사용자에게 편리하게 사용 할 수 있도록 반환 해준다.
지금은 Mybatis등등을 사용하여 DAO를 별도로 만드는 경우는 드물다고 한다.
Clinet <-DTO-> Controller <-DTO-> Service <-DTO-> Repository
public class User {
String UserID;
String Password;
public String getUserID() {
return UserID;
}
public void setUserID(String userID) {
UserID = userID;
}
public String getPassword() {
return Password;
}
public void setPassword(String password) {
Password = password;
}
}
When programming, I often find it's useful to represent things as a compound.
A 2D coordinate consists of an x value and y value. An amount of money consists of a number and a currency.
A date range consists of start and end dates, which themselves can be compounds of year, month, and day.
이처럼 "객체" 그 자체에 주목해야 한다.
즉, 객체의 같고 다름, 불변성 에 집중하여야 한다.
그렇다면 당연히?
VO를 사용함으로써
1. 예상되는 인스턴스를 미리 만들어 인스턴스를 생성해놓고 캐싱하여 성능을 높이는 방법도 있다고 한다. (나의 응애 레벨에서는 이게 무슨소리지? 하는 중이다.)
2. Entity의 원시값들을 VO로 포장하면 Entity의 거대화를 막아 테이블관점에서 객체지향관점으로 프로그래밍 가능하다. (1.을 읽고 느낀 감정과 유사하다.)
DB 테이블과 1:1 매핑되는 객체
비지니스 로직을 포함할수도, setter 메소드를 포함 할수도 있다.
"Entity를 데이터를 전달하는 클래스로 사용하면 안된다"
->DB와 맵핑됨으로
Clinet <-DTO-> Controller <-DTO-> Service <-DTO-> Repository <-Entity-> DB
나의 github에 있는 회원가입 기능에서의 VO는 사실 DTO를 사용해버린 것을 알았다.
많은 VO들이 DTO로 혼용되는 경우 또한 많다고 한다.
DTO | VO | Entity | |
---|---|---|---|
용도 | 레이어 간의 데이터 전송(DB직접X). | 객체 지향의 관점. | DB와 직접 맵핑 되는 클래스. |
가변/불변 | 가변 | 불변 | 가변 |
로직 포함 여부 | 불포함 | 포함 | 포함 |
나의 갈증이였던, 개인 프로젝트에서 클래스 생성에 대하여 정리가 좀 되었다.
https://velog.io/@ha0kim/DAO-DTO-VO-%EC%B0%A8%EC%9D%B4
https://www.youtube.com/watch?v=J_Dr6R0Ov8E
https://tecoble.techcourse.co.kr/post/2020-06-11-value-object/
https://melonicedlatte.com/2021/07/24/231500.html