Entity, DTO, DAO에 대해 알아보기 전에, 전체적인 구조를 먼저 확인해보자.

Entity

데이터 베이스 내 한 개의 테이블을 나타내는 객체.

Entity는 DB의 테이블과 1대1로 대응하며, 테이블에 가지지 않는 칼럼을 필드로 가져서는 안된다.
만약, DB의 Employee라는 테이블에 id, name, age 칼럼이 있다고 하자.

@Entity
public class Employee {
	@Id
    private Long id;
    
    private String name;
    
    private int age;
}

이에 대응하는 Entity 클래스 Employee는 위와 같은 필드만 가져야 한다.

DTO

Data Transfer Object로, 계층 간 데이터 교환을 하기 위해 사용하는 객체.

DTO는 순수한 데이터 객체로써 속성과 그 속성에 접근하기 위한 getter, setter 메서드만 가진 클래스다.(추가적으로 toString(), equals()등의 Object 클래스 메서드를 작성할 수 있다.)

MVC 패턴에서 Controller는 View와 Model의 데이터를 주고 받을 때 별도의 DTO를 주로 사용한다. 도메인 객체를 View에 직접 전달한다면, 도메인 비즈니스 기능이 노출될 수 있고, Model과 View 사이에 의존성이 생긴다.

DTO는 DB에서 꺼낸 데이터를 저장하는 Entity를 가지고 만드는 일종의 Wrapper 클래스라고 볼 수 있는데, Entity를 Controller와 같은 클라이언트단과 직접 마주하는 계층에 직접 전달하는 대신 DTO를 사용해 데이터를 교환한다.

예시

User.java

public calss User {
	public long id;
    public String name;
    public String email;
    public String pwd;
    public DetailInfo detailInfo;
    
    // 메서드 생략

UserController.java

@GetMapping
public RepositoryEntity<User> showArticle(@PathVariable Long id) {
	User user = userService.findByUd(id);
    return ResponseEntity.ok().body(user);

위 코드는 Controller가 클라이언트의 요청에 User를 넘겨준다. 이에 대해 생기는 문제점으로는,

• Model의 정보가 외부에 노출된다.
• UI 계층에서 Model의 메서드를 호출하거나 상태를 변경시킬 수 있다.
• Model과 View가 결합되어, View의 요구사항 변화가 Model에 영향을 끼칠 수 있다.

하지만 DTO를 사용한다면,

UserDto.java

public class UserDto {
	public final long id;
    public final String name;
    public final String email;
    
    public static UserDto from(User user) {
    return new UserDto(user.getId(), user.getName(), user.getEmail());
    }
}

UserController.java

@GetMapping
public ResonseEntity<userDto> showArticle(@PathVariable Long id) {
	User user = userService.findById(id);
    return ResponseEntity.ok().body(UserDto.from(user));
}

DTO를 사용하면 Model을 캡슐화하고, UI화면에서 사용하는 데이터만 선택적으로 보낼 수 있다. 즉, DTO는 클라이언트 요청에 포함된 데이터를 담아 서버 측에 전달하고, 서버 측의 응답 데이터를 담아 클라이언트에 전달하는 계층간 전달자 역할을 한다.

DAO

DB의 data에 접근하기 위한 객체로 실제로 DB에 접근하는 객체이다.

프로젝트의 서비스 모델과 실제 DB를연결하는 역할을 하며, JPA에서는 DB에 데이터를 CRUD하는 Repository 객체들이 DAO라고 볼 수 있다.

여기서 Repository는 Entity 객체를 보관하고 관리하는 저장소이고 DAO는 데이터에 접근하도록 DB접근 관련 로직을 모아둔 객체이다. 이 둘은 개념의 차이고 실제 개발할 때는 비슷하게 사용된다.

DAO vs DTO

DAO는 DB에 접속, 명령 전송을 전담하는 클래스이고, DTO는 특정 테이블의 정보를 레코드 단위로 정의해놓은 클래스이다.

예를 들어, DB에 어떤 학교의 학과번호, 학과명, 학생수를 관리하는 테이블이 있다고 가정해보자.

ID	NAME	NUM
1	Computer Science	483
2	Biotechnology	483
3	Mathematics	154

이 때 레코드를 하나의 자료형으로 다루기 위해 정의한 클래스를 DTO라고 부른다.

public class DepartmentDTO {
	private int id;
    private String name;
    private int num;
    
    public int getId() {
    	return id;
    }
    
    public void setId(int id) {
    	this.id = id;
    }
    
    public String getName() {
    	retrun name;
    }
    
    public void setName(String name) {
    	this.name = name;
    }
    
    public int getNum() {
		return num;
    }
    
    public void setNum(int num) {
		this.num = num;
    }
}

이에 반해 DAO는 이 DTO 정보를 저장하기 위해 DB와의 연결만을 전담하는 클래스다.

Reference

https://kbwplace.tistory.com/162

https://velog.io/@modsiw/Spring-DTO%EB%9E%80

https://velog.io/@rockwellvinca/Spring-Entitiy-DTO-DAO%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80