DTO와 ENTITY를 구분해서 구현한 이유

Entity vs DTO

• DTO 객체는 view layer와 데이터를 주고받을 때 사용한다.
• Entity 객체는 db layer와 데이터를 주고받을 때 사용한다.

Entity가 변경되면 여러 클래스에 영향을 끼치게 되는 반면 request와 response용 DTO는 view 를 위한 클래스라 정말 자주 변경이 되기 때문에 구분해서 사용해야 한다.

Entity

실제 데이터베이스 테이블과 매핑되는 클래스로 데이터베이스의 영속성(Persistent)의 목적으로 사용되는 객체이다.

• 많은 Service 클래스와 비즈니스 로직들이 Entity 클래스를 기준으로 동작하기 때문에 Entity 클래스가 변경되면 여러 클래스에 영향을 줄 수 있다.
  -> 필요한 요청과 사용자 View에 보이는 값이 달라질 때마다 Entity를 변경 할 수 없기 때문에 Request나 Response값을 전달하는 DTO를 따로 구분해서 구현을 한다.
• setter 메소드 사용 지양 (setter가 있다는 것은 불변하지 않다는 것)
• Entity에는 setter 대신 Constructor(생성자) 또는 Builder 사용

DTO

Data Transfer Object로 계층 간 데이터 교환이 이루어질 수 있도록 하는 객체이다.

• JSON serialization과 같은 직렬화에 사용
• setter 메소드를 가지는 경우 가변 객체로 활용 가능
• getter나 setter 메소드 외의 다른 비즈니스 로직은 포함하지 않는다.

Entity와 DTO를 분리하는 이유

Entity와 DTO를 분리하는 가장 큰 이유는 DB 와 View사이의 역할을 분리하기 위힘이다. 아래와 같이 Entity와 DTO의 목적이 다르기 때문에 구분해서 구현해야 한다.

• DTO의 목적은 전달
  : view와 통신하기 때문에 UI 요건에 따라 자주변경 될 수 있다.
• Entity의 목적은 테이블 매핑
  : 테이블에 매핑되는 정보가 실제 view 에서 원하는 정보와 다를 수 있기 때문에 변환하는 로직이 entity에 들어가게 된다면 Entity가 지저분해진다.

⇒ DB로부터 조회한 모든 엔티티를 뷰로 넘기게 되면 원하지 않는 정보까지 전달하게 되어 정보 노출에 대한 문제가 생길 수 있고 이를 막기 위한 비지니스 로직과는 상관없는 방어 로직들이 생기게 된다.