DAO과 DTO그리고 Entity

참고내용)

[ Spring ] 12. DAO & DTO & Entity와 스프링 패키지의 전체 구조 (tistory.com)

[ Spring ] 12. DAO & DTO & Entity와 스프링 패키지의 전체 구조

https://gmlwjd9405.github.io/2018/12/25/difference-dao-dto-entity.html

[DAO] DAO, DTO, Entity Class의 차이 - Heee's Development Blog

https://velog.io/@ohzzi/Entity-DAO-DTO가-무엇이며-왜-사용할까

Entity, DAO, DTO가 무엇이며 왜 사용할까?

https://iri-kang.tistory.com/5

DAO, DTO(VO) 란 무엇일까?

 

 

DAO (Data Access Object)

데이터베이스의 데이터에 접근하기 위해 생성하는 객체이다.

데이터베이스에 접근하기 위한 로직과 비즈니스 로직을 분리하기 위해 사용한다.

 

DB에 접속하여 데이터의 CRUD(생성, 읽기, 갱신, 삭제) 작업을 시행하는 클래스이다.

JSP 및 Servlet 페이지 내에 로직을 기술하여 사용할 수 있지만, 코드의 간결화 및 모듈화,

유지보수 등의 목적을 위해 별도의 DAO 클래스를 생성하여 사용하는 것이 좋다.

 

한 줄 요약 : DAO는 DB를 사용하여 데이터의 조회 및 조작하는 기능을 전담하는 오브젝트이다.

 

 

 

DTO(Data Transfer Object)

계층간 데이터 교환을 위한 객체(Java Beans)이다.

• DB에서 데이터를 얻어 Service나 Controller 등으터 보낼 때 사용하는 객체를 말한다.
• 즉, DB의 데이터가 Presentation Logic Tier로 넘어오게 될 때는 DTO의 모습으로 바껴서 오고가는 것이다.
• 로직을 갖고 있지 않는 순수한 데이터 객체이며, getter/setter 메서드만을 갖는다.
• 하지만 DB에서 꺼낸 값을 임의로 변경할 필요가 없기 때문에 DTO클래스에는 setter가 없다. (대신 생성자에서 값을 할당한다.)

 

Request와 Response용 DTO는 View를 위한 클래스

• 자주 변경이 필요한 클래스
• Presentation Model
• toEntity() 메서드를 통해서 DTO에서 필요한 부분을 이용하여 Entity로 만든다.
• 또한 Controller Layer에서 Response DTO 형태로 Client에 전달한다.

 

참고) VO(Value Object) vs DTO

VO	DTO
VO는 특정한 비즈니스 값을 담는 객체이다. (읽기만 가능)	DTO는 Layer간의 통신 용도로 오고가는 객체를 말한다.

 

 

Entity Class  

클래스는 DB의 테이블에 존재하는 Column들을 필드로 가지는 객체를 말한다.

Entity는 DB의 테이블과 1대 1로 대응되며, 때문에 테이블이 가지지 않는 컬럼을 필드로 가져서는 안된다.

또한 Entity 클래스는 다른 클래스를 상속받거나 인터페이스의 구현체여서는 안된다.

 

 

JPA를 사용할 때 Entity 클래스에는 @Entity 어노테이션을 붙여서

Entity임을 명시해 줘야 하며, 내부의 필드에는 @Column, @Id 어노테이션 등을 사용한다.

 

 

Entity는 외부에서 최대한 Entity의 Getter를 사용하지 않도록 내부에 로직을 구현하는데,

이 때 Domain 로직만 구현하고 Presentation 로직은 구현하지 않는다.

여기서 구현한 method는 주로 Service Layer에서 사용한다.

 

 

참고 Entity 클래스와 DTO 클래스를 분리하는 이유

• View Layer와 DB Layer의 역할을 철저하게 분리하기 위해서
• 테이블과 매핑되는 Entity 클래스가 변경되면 여러 클래스에 영향을 끼치게 되는 반면
  → View와 통신하는 DTO 클래스(Request / Response 클래스)는 자주 변경되므로 분리해야 한다.
• Domain Model을 아무리 잘 설계했다고 해도 각 View 내에서 Domain Model의 getter만을 이용해서 원하는 정보를 표시하기가 어려운 경우가 종종 있다.
  →이런 경우 Domain Model 내에 Presentation을 위한 필드나 로직을 추가하게 되는데, 이러한 방식이 모델링의 순수성을 깨고 Domain Model 객체를 망가뜨리게 된다.
• 또한 Domain Model을 복잡하게 조합한 형태의 Presentation 요구 사항들이 있기 때문에 Domain Model을 직접 사용하는 것은 어렵다.
• 즉 DTO는 Domain Model을 복사한 형태로,
  → 다양한 Presentation Logic을 추가한 정도로 사용하며 Domain Model 객체는 Persistent만을 위해서 사용한다.