-
Notifications
You must be signed in to change notification settings - Fork 11
용어정리 dto vo entity dao
데이터를 담은 객체들이 계층을 오고가며 역할과 기능이 달라지는 경우에 정의(definition)의 혼동을 막고자 사용되면 이롭다. @JooHyukKim
아니다.
데이터를 담은 객체들이 복수의 역할을 수행하는 경우에는 오히려 혼동을 일으킨다.
그러니 실제로 객체들이 계층별로 역할, 또는 기능이 달라진 경우가 아닌 이상 커뮤니케이션 과정에서 피해야한다.
대신 데이터나 Model와 같은 단순한 단어들로 커뮤니케이션 이루어져야한다. @JooHyukKim
Martin Folwer 가 "P of EAA" 라는 책에서 언급하기 시작한 객체 사용 패턴. 계층간 데이터를 주고 받는 횟수를 줄이기 위해 여러 객체/데이터를 하나의 객체에 담아 데이터를 전달하기 위한 목적으로 쓰인다. 여러 레이어 사이에서 DTO를 사용할 수 있다. 화면 구성을 위해 다양한 타입의 데이터를 필요로 하는 경우가 많은 View와 Controller 사이에서 주로 활용한다. DTO는 값 전달만 해야하기 때문에 getter/setter 메소드만 포함한다. 이 외의 비즈니스 로직은 포함하지 않는다.
VO는 비즈니스/도메인의 값 자체를 표현하는 객체이다. VO는 객체들의 주소가 달라도 값이 같으면 동일한 것으로 여긴다.
예를 들어, 고유번호가 서로 다른 만원 2장이 있다고 생각하자. 이 둘은 고유번호(주소)는 다르지만 10000원(값)은 동일하다.
VO는 getter 메소드와 함께 비즈니스 로직도 포함할 수 있다. 단, setter 메소드는 가지지 않는다. 또, 값 비교를 위해 equals()와 hashCode() 메소드를 오버라이딩 해줘야 한다.
Entity는 실제 DB 테이블과 매핑되는 핵심 클래스이다. 이를 기준으로 테이블이 생성되고 스키마가 변경된다. 따라서, 절대로 Entity를 요청이나 응답값을 전달하는 클래스로 사용해서는 안 된다. Entity는 id로 구분된다. 그리고 비즈니스 로직을 포함할 수 있다
DAO 는 DB 를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 오브젝트를 말한다.
-
Business Rules
-
Project Rules