[Persistence Framework] Model(DAO, DTO, Service)

Spring MVC 모델에서 Model은 application의 상태를, 곧 데이터를 나타내며, 구체적으로는 DAO, DTO, Service로 나눌 수 있다.

 

스프링 Service & DAO 객체 구현

engkimbs.tistory.com/692

 

스프링 MVC

gmlwjd9405.github.io/2018/12/20/spring-mvc-framework.html

 

싱글톤 패턴

velog.io/@kyle/%EC%9E%90%EB%B0%94-%EC%8B%B1%EA%B8%80%ED%86%A4-%ED%8C%A8%ED%84%B4-Singleton-Pattern

 

VO 설명(우테코)

velog.io/@livenow/Java-VOValue-Object%EB%9E%80

 

Entity, VO, DTO

velog.io/@gillog/Entity-DTO-VO-%EB%B0%94%EB%A1%9C-%EC%95%8C%EA%B8%B0

 

DAO(Data Access Object)

이름 그대로 데이터에 접근하는 객체이다. 즉 DB를 사용해서 CRUD를 수행하는 객체이다. 그렇다면 이러한 객체는 왜 필요할까? 비즈니스 로직(고수준)을 담은 코드가 DB 접근을 위해 드라이버도 로드하고 직접 Connection 객체까지 생성(저수준)하는 것은 오버헤드가 클 뿐 아니라 산발적으로 중복된 작업을 할 가능성이 있다. 하지만 이러한 작업을 전담하는 DAO가 별도로 존재한다면 부담은 줄어들게 된다. 또한 DB 접근과 관련한 동작을 숨길 수 있어 보안이 향상된다.

관련된 개념으로 DBCP(DataBase Connection Pool)이 있다. 컴퓨터공학에서 pool이라는 용어를 만나면 대개 사용할 수 있도록 준비시켜둔 리소스라고 생각하면 된다. 곧 DBCP는 DB와의 Connection 객체들의 pool로서, WAS가 실행될 때 미리 일정한 개수의 Connection 객체를 만들어두고 연결 요청이 올 때마다 이 pool에서 필요한 Connection 객체를 사용한 후 다시 반환하도록 하는 것이다. 물론 DB 접근 요청이 굉장히 적으면 비효율적이겠지만, 대부분의 경우 굉장히 효율적이라고 할 수 있다.

 

EmpDao.java

public interface EmpDao {
    public List<Emp> getEmp();
}

 

EmpDaoImpl.java

@Repository("empDao")
public class EmpDaoImpl implements EmpDao {
    @Override
    public List<Emp> getEmps() {
        List<Emp> res = new ArrayList<>();
        // res.add(...)
        return res;
    }
}

 

DTO(Data Transfer Object)  vs VO(Value Object)

DTO vs VO(Value Object): ijbgo.tistory.com/9

 

DTO는 데이터 전송 및 이동을 위한 객체, 곧 계층간 데이터 교환을 위한 Bean 객체로서 주로 비동기 처리를 할 때 사용한다. DB의 데이터를 Service나 Controller 등으로 보낼 때, 즉 레이어간 통신 용도로 사용하는 객체를 의미한다.

즉 DB의 데이터가 Presentation Logic Tier로 넘어올 때에는 DTO로 변환되어 오가는 것이다.

로직을 갖고 있지 않는 순수한 데이터 객체이며, getter/setter 메서드만을 갖는다.

Controller Layer에서 Response DTO 형태로 Client에 전달한다.

 

일반적인 흐름

 

서버측: Database Column Data -> DTO -> API(JSON or XML) -> Client

클라이언트측: Server -> API(JSON or XML) -> DTO -> View or Local Database System

 

VO는 특정한 비즈니스 값을 담는 객체. read only 속성을 갖는다.

값 변경이 없음.

데이터 그 자체로 의미있는 것을 담고 있음

간단한 독립체(Entity)를 의미하는 작은 객체를 의미함

RDB의 레코드에 대응되는 자바 클래스

DB의 레코드를 구성하는 필드들을 VO의 attribute로 하고 해당 변수에 접근할 수 있는 getter+setters

거의 불변성.

equals()는 모든 값 비교하도록 오버라이딩해야한다.

(상태가 변하지 않는 BaseVO 클래스를 상속받을 수 있음)

(BaseVO 클래스: 여러 테이블에 대한 공통속성을 모아서 만든 클래스)

 

장점

네트워크 트래픽을 줄일 수 있다.(왜???)

비서버측 클라이언트도 네트워크 오버헤드 없이 영속성 데이터에 액세스 할 수 있다.(역시나 왜???)

이거 두 장점은 잘 모르겠다.

 

단점

클래스 선언을 위해 코드가 필요하고 파일 수 증가, 관리 힘들어짐 등

 

 

Service

비즈니스 로직이 들어가는 부분.

Controller가 request를 받으면 적절한 Service에 전달하고, 비즈니스 로직을 가지고 있는 Service는 해당 request를 처리한다. 이 과정에서 DAO를 통해서 DB에 접근하며, 데이터를 전달받을 때에는 DTO를 이용하는 것이다. 이를 위해서 Service 클래스는 필드 변수로 DAO 객체를 가진다.

또 하나의 중요한 Service의 역할은 트랜잭션을 담당하는 것이다. 만약 계좌이체라는 기능이 있다면, 이는 물리적으로는 2개의 작업이지만 사용자의 입장에서는 1개의 작업이다. 이는 Service단에서 해결한다.