Dto / Entity(=Domain) 차이점

1. Dto(Data Transfer Object)

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

DB에서 데이터를 얻어 Service나 Controller등으로 보낼때 사용하는 객체

계층간의 데이터 교환이 이루어 질 수 있도록 하는 객체이기 때문에 특별한 로직을 갖고 있지 않은 순수한 데이터 객체여야하며, getter/setter 메서드만을 갖는다.

DB에서 꺼낸 값을 임의로 변경할 필요가 없기 때문에 DTO클래스에는 가급적 setter사용을 지양한다. (대신 생성자에서 값을 할당한다.)

 

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

자주 변경이 필요한 클래스

Presentation Model

toEntity() 메서드를 통해서 DTO에서 필요한 부분을 Entity로 만듬

Controller Layer에서 Response DTO 형태로 Client에 전달

주로 API 데이터를 반환하거나 읽기 모델에 사용

 

※ VO(Value Object) vs DTO

VO는 DTO와 동일한 개념이지만 read only 속성을 갖는다.

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

 

2. Entity(=Domain)

DB 테이블에 존재하는 Column들을 필드로 가지는 객체

테이블과 링크될 클래스임

DB의 테이블과 1대 1로 대응(테이블이 가지지 않는 컬럼을 필드로 가져서는 안됨)

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

@Entity, @Column, @Id 등을 이용

 

최대한 외부에서 Entity 클래스의 getter method를 사용하지 않도록 해당 클래스 안에서 필요한 로직 method를 구현

Domain Logic만 가지고 있어야 하고 Presentation Logic을 가지고 있어서는 안된다.

구현한 method는 주로 Service Layer에서 사용

 

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

Entity는 DB Layer를 위한, DTO는 View Layer를 위한 것으로 역할을 분리하기 위함.

Entity는 실제 테이블과 매핑되어 만일 변경 되게 되면 여러 다른 클래스에 영향을 끼치고,DTO 클래스(Request / Response 클래스)는 View와 통신하며 자주 변경되므로 분리 필요.

 

※ @Controller 와 @RestController

 

[@Controller]

@Controller은 뷰에 표시될 데이터가 있는 Model 객체를 만들고 올바른 뷰를 선택하는 일을 담당

@ResponseBody를 사용하여 HTTP Response Body에 데이터를 담아 요청을 완료할 수 있다.

 

 

[@RestController]

Spring MVC Controlle에 @ResponseBody가 추가된 것.

RestController의 주용도는 Json형태로 객체 데이터를 반환 하는 것.

⇒ @Controller와 @ResponseBody를 사용하여 만들 수 있지만 이러한 방식은 RESTful 웹서비스의 기본 동작이기 때문에 Spring은 @Controll와 @ResponseBody의 동작을 조합한 @RestController을 도입

@Controller @ResponseBody public class MVCController{ }

@RestController public class ReftFulcontroller{ }

 

※ RestController와 @Service를 나누는 이유

@Service를 만들어서 나누는 이유는 중복되는 코드가 생기기 때문

비즈니스 로직은 다른 요청 URL에서 사용해야 하는 경우가 있다. 만약 비즈니스 로직 코드가 컨트롤러에 구현되어 있는 경우, 다른 컨트롤러의 핸들러 메소드에서 똑같은 로직코드를 구현해야하니 중복코드가 발생하고 재사용성이 줄어든다.

중복되는 코드가 발생하면 따로 모듈화를 해서 나눠주는 것이 유지 보수하기 편리하다. (NodeJS => 모듈화)

모든 기능들을 세분화해서 @Service에 작성하게 되면 나중에는 서비스의 기능들을 조합만 해서 새로운 기능을 만들 수 있음

서비스에서 다른 서비스를 의존성 참조하는 것도 가능하다.

 

즉, 비즈니스 로직의 서비스 구현체에서 구현하는 이유는 바로 확장성과 재사용성 그리고 중복 코드의 제거이다.