MVC를 구현하며 DTO와 VO의 정확한 차이를 이해하지 못하다보니 사용을 하면서도 확신이 없고, 괜히 더 어려운 듯한 느낌이 들었다. 모호하게 알거나, 모른 채 지나가버리면 나중에 힘드니 오늘은 한번 집중적으로 알아보기로 한다.

DTO

순수하게 데이터를 담아 계층 간으로 전달하는 객체.
로직을 갖고 있지 않은 순수한 데이터 객체이며 메서드로는 getter/setter 만을 갖는다.

• Q.
  : DTO가 getter/setter 이외에 다른 로직이 필요 없는 이유는 뭘까?
  DTO는 데이터 전달 만을 위한 객체라 하였는데, 따라서 완전히 데이터 '전달' 용도로만 사용하기 때문에 이외의 로직이 필요하지 않은 것이다.
• 보내는 쪽에서는 setter를 이용하여 값을 전달하고, 받는 쪽에서는 getter를 이용하여 값을 꺼내 쓰게 된다.
  이때 값의 변조를 막고 싶다면 생성자로 불변 객체로 만들어 버리면 된다.
  결국 DTO는 단지 데이터를 담는 그릇의 역할일 뿐 값은 그저 전달되어져야할 대상일 뿐이다.

VO

값 그 자체를 나타내는 객체. (read only)

• 객체의 불변성(객체의 정보가 변경하지 않음)을 보장한다.
  DTO와는 다르게 로직을 포함할 수 있으며, VO의 경우 특정 값 자체를 표현하기 때문에 불변성의 보장을 위해 생성자를 사용하여야 한다.
• VO는 객체들의 주소가 달라도 값이 같으면 동일한 것으로 여긴다. 예를 들어, 고유번호가 서로 다른 만원 2장이 있다고 하면, 이 둘은 고유번호(주소)는 다르지만 10000원(값)은 동일한 것.
  즉, VO는 값 그 자체를 나타내기 때문에 setter 같은 성격의 변조 가능성이 있는 메서드가 존재하면 안되며, 두 객체의 필드 값이 같다면 모두 같은 객체로 만드는 것이 핵심이다.
  이를 위해 VO에는 Object 클래스이 equals() 와 hashCode()를 오버라이딩 한다.

Entity

실제 DB테이블과 매핑되는 핵심 클래스이다.
이를 기준으로 테이블이 생성되고 스키마가 변경되며, 절대로 Entity를 요청이나 응답값을 전달하는 클래스로 사용하여서는 안된다.
보통 id로 구분하며, 비즈니스 로직을 포함할 수 있다.