다른 분들의 프로젝트를 구조분석하다가
DTO라는 단어가 자주 등장해서
개념을 정리해보았습니다.
계층 간 데이터을 이동하기 위해 사용하는 객체
로직을 가지지 않는 순수한 데이터 객체(getter와 setter만 가진 클래스)
하지만 DTO는 단순히 데이터를 옮기는 용도이기 때문에 굳이 setter를 이용해 수정할 필요가 없이 생성자만을 사용하여 값을 할당하게 좋습니다.
Controller와 Service, Repository 계층 사이에 데이터가 오갈 때도 데이터는 DTO 형태로 이동하게 됩니다.
여기서 궁금증이 생겼습니다.
Entity 객체를 그대로 사용하지 않고 DTO를 사용하는 이유는 뭘까?
DAO(Data Access Object)는 데이터 베이스의 data에 접근하기 위한 객체
database에 접근하기 위한 로직과 비즈니스 로직을 분리하기 위해 사용합니다.
여기서 두 가지 궁금증이 생겼습니다.
DAO는 Service가 아닌가? ❌
결국 생각해보면 Service는 사용자의 요청을 하나의 작업으로 묶었고 그안에 DAO가 조립된 것처럼 들어가 있는 것입니다.
DAO는 Repository가 아닌가? ⭕or❌
JPA의 경우 Repository가 DAO의 역할을 한다고 볼 수 있지만 같은 것은 아닙니다.
DAO와 REPOSITORY 모두 퍼시스턴스 로직에 대한 객체-지향적인 인터페이스를 제공하고
도메인 로직과 퍼시스턴스 로직을 분리하여 관심의 분리
(separation of concerns) 원리를 만족시키는데 목적이 있다.
그러나 비록 의도와 인터페이스의 메소드 시그니처에
유사성이 존재한다고 해서 DAO와 REPOSITORY를 동일한
패턴으로 취급하는 것은 성급한 일반화의 오류를 범하는 것이다.
DAO는 퍼시스턴스 로직인 Entity Bean을 대체하기 위해
만들어진 개념이다. DAO가 비록 객체-지향적인 인터페이스를
제공하려는 의도를 가지고 있다고 하더라도 실제 개발 시에는
하부의 퍼시스턴스 메커니즘이 데이터베이스라는 사실을 숨기려고
하지 않는다. DAO의 인터페이스는 데이터베이스의 CRUD 쿼리와
1:1 매칭되는 세밀한 단위의 오퍼레이션을 제공한다.
반면 REPOSITORY는 메모리에 로드된 객체 컬렉션에 대한 집합 처리를 위한 인터페이스를 제공한다.
DAO가 제공하는 오퍼레이션이 REPOSITORY 가 제공하는 오퍼레이션보다 더 세밀하며,
결과적으로 REPOSITORY에서 제공하는 하나의 오퍼레이션이 DAO의 여러 오퍼레이션에 매핑되는 것이 일반적이다.
따라서 하나의 REPOSITORY 내부에서 다수의 DAO를 호출하는 방식으로 REPOSITORY를 구현할 수 있다.
reference:http://egloos.zum.com/aeternum/v/1160846
Value Object로 값 오브젝트로써 값을 위해 쓰입니다.
read-Only 특징으 가지며 DTO와 유사하지만 DTO는 setter를 가지고 있어 값이 변할 수 있습니다.
https://gaebalsogi.tistory.com/39
https://ysyapr91.tistory.com/4
https://melonicedlatte.com/2021/07/24/231500.html