[백엔드 기술 면접 대비] - 1. Entity, DAO, DTO, VO란?
오늘은 데이터 컨트롤의 기초라고 볼 수있는, 데이터 객체들에 대해 한 번 짚고 넘어간다.
Entity란?
Entity는 도메인 모델 객체로서, 실제 테이블과 매핑되어 변경 될 시 다른 여러 Class에 영향을 미치게 된다.
Entity는 다음 특징들이 있다.
- DB의 테이블과 1대 1로 대응된다.
- DB의 테이블이 가지지 않은 칼럼을 필드로 가져선 안된다.
- 다른 클래스를 상속받거나 인터페이스의 구현체여서는 안된다.
- Setter 사용을 지양한다.
여기서 Setter 사용을 지양하는 이유는 , Setter의 사용이 Entity의 일관성을 해칠 수 있기 때문이라고 한다.
따라서 Setter 대신 다른 방법으로 필드에 값을 넣어 주는 것이 좋다.
또한 Entity를 생성할 때는 Builder 패턴을 사용하는 것이 가장 추천된다.
DAO(Data Access Object)란?
말 그대로, 데이터베이스의 데이터에 접근하기 위한 객체이다.
비즈니스 로직에서 오직 데이터에 접근하는 로직만을 분리한 객체인데, 직접 DB에 접근해 삽입, 삭제, 조회 등 데이터를 조작하는 기능을 수행한다.
MVC패턴의 경우 Model에서 이 작업을 수행하고, JPA에서는 Repository 객체가 DAO를 대체한다고 볼 수 있다.
DAO 와 Repository의 차이는 다음과 같다고 한다.
DAO와 REPOSITORY 모두 퍼시스턴스 로직에 대한 객체-지향적인 인터페이스를 제공하고 도메인 로직과 퍼시스턴스 로직을 분리하여 관심의 분리(separation of concerns) 원리를 만족시키는데 목적이 있다. 그러나 비록 의도와 인터페이스의 메소드 시그니처에 유사성이 존재한다고 해서 DAO와 REPOSITORY를 동일한 패턴으로 취급하는 것은 성급한 일반화의 오류를 범하는 것이다.
DAO는 퍼시스턴스 로직인 Entity Bean을 대체하기 위해 만들어진 개념이다. DAO가 비록 객체-지향적인 인터페이스를 제공하려는 의도를 가지고 있다고 하더라도 실제 개발 시에는 하부의 퍼시스턴스 메커니즘이 데이터베이스라는 사실을 숨기려고 하지 않는다. DAO의 인터페이스는 데이터베이스의 CRUD 쿼리와 1:1 매칭되는 세밀한 단위의 오퍼레이션을 제공한다. 반면 REPOSITORY는 메모리에 로드된 객체 컬렉션에 대한 집합 처리를 위한 인터페이스를 제공한다. DAO가 제공하는 오퍼레이션이 REPOSITORY 가 제공하는 오퍼레이션보다 더 세밀하며, 결과적으로 REPOSITORY에서 제공하는 하나의 오퍼레이션이 DAO의 여러 오퍼레이션에 매핑되는 것이 일반적이다. 따라서 하나의 REPOSITORY 내부에서 다수의 DAO를 호출하는 방식으로 REPOSITORY를 구현할 수 있다.
출처 :
http://egloos.zum.com/aeternum/v/1160846
DTO(Data Transfer Object)란?
DTO란 계층간 데이터 전송을 할때, 도메인 모델 대신 사용하는 객체이다.
DTO는 어떠한 비즈니스 로직을 가져서도 안되고, 오직 데이터에 대한 getter, setter만을 가져야 한다.
오로지 저장, 검색, 직렬화, 역직렬화 로직만을 가져야한다.
직렬화는 DTO를 Byte, Json, Xml 등의 형태로 변환하는 것을 의미한다. 역직렬화는 그 반대를 의미.
DTO를 도메인 모델로 변환할 때는 별도로 Mapper 객체를 사용한다고 한다.
DTO를 사용하는 이유
도메인 대신 DTO를 사용하면 좋은 점은, 필요한 정보만을 제공할 수 있고, 도메인 모델을 캡슐화하여 보호할 수 있다.
그리고 도메인 모델을 계층간 전송에 사용하면, 모델과 뷰가 결합되어 결합도가 높아질 수 있다.
뷰의 요구사항 변화에도 유연하게 대처하려면 DTO를 사용하여 결합도를 낮추는 것이 중요하다.
VO(Value Object)란?
VO는 오로지 값 오브젝트로서 값을 위해 쓰인다.
Read-Only특징을 가지며, DTO와 유사하지만 VO는 getter 기능만을 가진다.
VO는 값 자체에 의미가 있고, DTO는 값을 전달하는 그릇일 뿐이라고 생각하면 된다.
Reference