VO
개념
Value Object는 DTO와 동일한 개념이나 차이 점은 read only 속성을 갖습니다.
Value Object는 관계데이터베이스의 레코드에 대응되는 자바클래스입니다. 형태는 db레코드를 구성하는 필드들을 Value Object의 Attribute로 하고 해당 변수에 접근 할 수 있는 Getter Setter 메소드의 조합으로 클래스를 형성되어진 클래스입니다. 특성은 대체로 불변성이고 equals()로 비교할 때 객체의 모든 값을 비교해야 합니다.
필요성
Network traffic을 줄임으로 인해서 효과적입니다.
기대효과
Network traffic이 줄어듭니다.
장 단점
장점으로는 비 서버 측 클라이언트도 네트워크 오버헤드 없이 영속성 데이터에 액세스 할 수 있다는 점입니다. 데이터 전달을 위해 가장 효율적인 방법이지만, 클래스의 선언을 위해 많은 코드가 필요합니다. 즉 파일수가 많아지게 되고 관리도 힘들어지게 됩니다.
예제 소스코드
view plaincopy to clipboardprint?
Public class Data extent ValueObject // VO패턴에 따라 상태가 변하지 않는 Immutable
{ // 클래스를 상속 받는다.
private String Data;
private int nNo;
public String getData() { return Data; }
public void setData(String data) {this.Data = data;}
public int getNumber() {return nNo;}
public void setNo(int no) { this.nNo = no;}
}
DTO
개념
데이터가 포함된 객체를 한 시스템에서 다른 시스템으로 전달하는 작업을 처리하는 객체입니다. Vo와 dto의 차이점은 vo는 특정한 비즈니스 값을 담는 객체를 vo라 하고 dto는 레이어간의 통신용도로 오가는 객체를 dto라고 합니다.
Vo와 DTO의 비교
DTO의 나머지 속성은 vo와 똑같다고 생각하여서 차라리 차이점을 비교하려고 합니다.
Core J2EE Patterns 라는 책에서는... Value Object랑 Transfer Object를 동일한 뜻으로 사용합니다만 반대로 Martin Fowler는 저서 Patterns of Enterprise Application Architecture에서 약간 다른 의미로 이야기 합니다. DTO는 메소드 호출 횟수를 줄이기 위해 데이터를 담고 있는 녀석으로, VO는 값이 같으면 동일 오브젝트라고 볼 수 있는 녀석으로 표현을 하고 있습니다.
쉽게
DTO a = new DTO(1);
DTO b = new DTO(1);
이라고 했을 때 a != b 이지만,
VO a = VO(1);
VO b = VO(1); 이라고 했을때는 a == b라고 정의하는 형태입니다.
사실 이러한 내용도 헷갈리는 부분이 있는게 대부분의 검색에서 사람들은 vo와 dto를 같은 개념으로 이야기 하고 있어서 아직도 vo와 dto가 “이런거다”라기 보다 거의 똑 같은 개념으로 생각하고 있습니다.
DAO
개념
데이터 접근을 목적하는 객체입니다. 커넥션 같은 것을 하나만 두고 여러 사용자가 DAO의 인터페이스를 사용하여 필요한 자료에 접근 하도록 하는 것이 DAO의 개념입니다.
필요성
모든 데이터베이스에 공통적으로 접속 할 수 있는 ODBC가 나왔지만 완벽하진 못했습니다. 여전히 로우 레벨의 API를 포함하고 있었기 때문에 개발 장벽이 여전히 높았습니다. 이런 이유 때문에 개발자들은 정작 데이터베이스에 들어 있는 데이터를 어떻게 이용할지에 초점을 맞추기 보다, 어떻게 데이터베이스에 접속해서 데이터베이스와 교류하는지에 더 초점을 기울였습니다. 즉 데이터를 활용하는 논리적 고민보다 기술적 고민에 더 많은 신경을 썻었습니다. 이런 이유로 DAO란 대안이 나왔습니다.
기대효과
사용자는 자신이 필요한 Interface를 DAO에게 던지고 DAO는 이 인터페이스를 구현한 객체를 사용자에게 편리하게 사용 할수 있도록 반환해줍니다.
장 단점
DB에 대한 접근을 DAO가 담당하도록 하여 데이터베이스 엑세스를 DAO에서만 하게 되면 다수의 원격호출을 통한 오버헤드를 VO나 DTO를 통해 줄일수 있고 다수의 DB 호출문제를 해결할 수 있습니다. 또한 단순히 읽기만 하는 연산이므로 트랜잭션 간의 오버헤드를 감소할 수 있습니다.
그러나 Persistent Storage를 너무 밀접하게 결합해서 작성을 하게 되면 Persistent Stroage를 다시 작성할 경우가 생기는데 이러한 경우 유지 보수의 문제가 생길수도 있습니다.
예제 소스코드
view plaincopy to clipboardprint?
// XXX 에 대한 DAO 생성자로 Connection 을 받습니다.
// 그러면 해당 DAO 인스턴스는 해당 Connection 을 계속 재사용하게 됩니다.
// 이 Connection 은 외부에서 넘겨 준것이므로 해당 DAO 는 release 는 할수 없습니다.
// DAO 에서는 ResultSet 과 Statement 만을 생성하고 close 합니다.
public class XXXDao {
Connection dbConnection = null;
public XXXDao( Connection dbConnection ) {
this.dbConnection = dbConnection ;
}
public Vector doXXXDBLogic( String param1 ) throws Exception {
// …
Statement stmt = null;
ResultSet rset = null;
try {
stmt = dbConnection.createStatement();
stmt.executeQuery( “select 어쩌구.. “);
// Vector 에 결과 저장 & return
} catch (Exception ex) {
// exception 처리
throw ex;
} finally {
DBUtil.closeStatement( stmt ) ; // statement close
DBUtil.closeResultSet( rset ) ; // resultset close
}
}
}