DAO
DAO는 Data Access Object의 약자로, 데이터에 접근하는 객체다.
Service에서 DB의 데이터를 다루기 위한 툴과 같은 역할을 한다.
아래 예시를 통해 살펴보자.
// 템플릿 설정 등을 완료했음을 상정한 예시 코드
@Repository
public class ExDao {
@Inject
SqlSession sqlSession;
public ExEntity getEx(String exId) {
return sqlSession.selectOne("...ExMapper.selectEx", exId);
// 개발된 상황에 따라 매핑된 sql문 호출은 달라질 수 있음
}
}DB의 CRUD를 수행하기 위한 메서드를 위처럼 정의한다.
SqlSession을 이용해 MyBatis로 매핑된 쿼리를 날리는 직접적인 역할을 하는 것이다.
이를 Service에서 가져가서 사용하는 것으로 DB의 데이터를 관리할 수 있게 된다.
DTO
DTO는 Data Transfer Object의 약자로, 데이터 교환을 위한 객체다.
@Data
@JsonInclude(JsonInclude.Include.NON_NULL)
@JsonIgnorProperties(ignoreUnknown = true)
public class ExDto {
private String orderBy;
private String exId;
private String exName;
private int exAge;
}DTO는 Layer간 데이터 교환이 이루어지도록 하는 객체로, Entity와 유사하지만 Entity와는 달리 각 레이어에서 주고받을 수 있는, 그저 데이터들을 담아둔 박스와 같은 객체다. 목적 자체가 데이터를 전달하는 것에 있기 때문에 읽고 쓰는 것이 모두 가능해서 getter, setter을 모두 설정할 수 있으며 일회성으로 데이터를 주고받는 것으로만 사용되는 성격이 강하다.
예를 들어, 가져온 데이터를 페이징한 결과를 view에서 요청할 때 DTO를 활용해 paging된 result를 보내는 데 사용할 수 있다. 이런 경우 Presentaion 로직이 추가로 요구되는데, 그러한 처리를 DTO에서 담당해 처리 후 데이터를 보내는 것이다. 이렇게 view에서 요청하는 정보와 테이블에 매핑된 정보가 다를 경우 그 데이터 변환 과정 로직을 담기 위해, 또는 불필요한 데이터의 노출을 막기 위해 사용될 수 있다.
DTO가 사용되는 방식은 프로젝트마다 성격이 다를 수 있으므로 맞춰서 작성하도록 하자.
한편 읽기 전용으로만 사용되는 DTO는 VO(Value Object)로 작성되기도 한다. 둘은 완벽히 같은 것이 아니고, VO는 setter 메서드를 가질 수 없으며 객체들의 주소 값이 다르더라도 데이터의 value가 같으면 동일한 것으로 처리하는 등의 차이점이 있다.
Entity
실제 DB의 테이블과 매칭시켜 링크하는 클래스다.
@Data
@JsonInclude(JsonInclude.Include.NON_NULL)
@JsonIgnorProperties(ignoreUnknown = true)
public class ExEntity implements Serializable {
private String exId;
private String exName;
private int exAge;
}위처럼 DB의 테이블에 존재하는 column들을 매핑하여 1:1 필드로 가지며 실제 DB에 존재하지 않는 칼럼은 가지지 않는다. 테이블과 링크되어 데이터들을 나타내는 코어한 클래스이기 때문에 Entity를 기준으로 많은 로직들이 설정되게 되므로 Entity의 내용이 변경되면 큰 영향을 보일 수 있다. DB의 영속성을 목적으로 사용되기 때문에 setter을 작성할 수는 있으나 지양하는 것이 좋으며 필요한 경우 생성자나 Builder를 사용한다.
참고한 페이지
https://wildeveloperetrain.tistory.com/101
https://gmlwjd9405.github.io/2018/12/25/difference-dao-dto-entity.html
