전부터 VO, DTO, DAO, Entity 등에 대해 명확한 이해를 갖기 어려웠다. 개념을 개념으로서만 풀어내고 끝내는 글들이 많아서인지, 자세한 설명들이 있음에도 불구하고 구체적인 사용 사례가 어떻게 구분되는지가 좀 난해했다. 특히 DAO가 무엇인지가 한참 감을 못잡았다. DTO와 Entity가 무엇인지 더 잘 알려면 DAO에 대해서도 알아야 했다. 이번 기회를 통해 정리해봤다.
개념
우선, 각 객체들의 잘 알려진 설명들을 보도록 하자. 개념 설명은 다음 자료를 참고하였다.
[Java] DAO, DTO, VO, Entity 란?
DAO
- DB에 접근하는 Java 객체
- 사용 라이브러리에 따라 코드의 생김새가 조금씩 다르나 기능과 사용 이유는 같음
DTO
- 계층간 데이터 교환을 위한 객체
Client→Server,Server→Client또는Controller→Service같은 Layer에서 사용- 순수 데이터 객체
- 로직을 가지지 않음(비즈니스 로직)
VO
- 단순 데이터 객체
- 데이터의 조작 불가
Entity
- DB 테이블과 1:1 매핑되는 객체
- JPA 사용시 주로 사용됨
DTO와 분리하여 사용하여야 함- 상속받거나, 구현체여서는 안된다.
이쯤에서 개념 이해는 부족하지만 이 객체들을 사용해본 입장에서는 몇가지 의문이 나타나게 된다.
DTO로도 DB에 접근할 수는 있고,DAO라고 해도 계층간 데이터 교환은 할 수 있을텐데,DTO와DAO는 정확히 어떤 차이지?- 보통
Entity를 통해 DB에 접근했던 것 같은데, DB에 접근하는 객체는DAO라는 게 무슨 말이지? DB에 접근하는 것과 DB 테이블에 1:1 매핑되는 건 무슨 차이지?
즉, DAO란 무엇인가.
DAO (Data Access Object)
앞선 의문에 대해 차차 풀어나가보도록 하자.
DAO vs DTO
DAO는 데이터베이스에 접근하고 데이터를 조작하는데 사용되는 객체로, 일반적으로 데이터베이스에 대한 접근을 캡슐화하고, 데이터베이스와의 통신을 처리한다. 이를테면, 데이터베이스 연결, 쿼리 실행, 트랜잭션 관리 등과 같은 데이터 액세스 로직을 처리하는 것이다. 데이터베이스와의 상호작용을 추상화하여 비즈니스 로직과 데이터 액세스 로직을 분리함으로써 코드의 모듈성과 유지보수성을 향상시킬 수 있다.
여기서 비즈니스 로직과 데이터 액세스 로직을 분리한다는 지점에서 DTO와 DAO의 성격이 드러난다. DAO를 통해 데이터 액세스 로직을 캡슐화하면, 비즈니스 로직에서는 DAO를 통해 가져온 데이터를 DTO로 변환하여 사용할 수 있다는 것이다. 즉, DAO가 데이터 액세스 로직을 처리하고 DTO가 비즈니스 로직에서 필요한 데이터를 캡슐화하여 전달하는 역할을 수행하게 된다.
이러한 로직의 차이는 이들이 사용되는 계층도 분리하게 되는데, 비즈니스 로직은 주로 컨트롤러 계층에서 구성되며, 컨트롤러는 클라이언의 요청을 처리하고 비즈니스 로직을 실행하여 필요한 데이터를 준비한다. 이때 DTO는 주로 컨트롤러 계층과 서비스 계층 사이에서 데이터 이동을 위해 사용된다.
이로써 데이터 액세스 로직을 추상화하는 DAO가 비즈니스 로직에서 사용되는 DTO와 명확히 구분된다는 것을 보였다.
그럼 이제 DAO와 Entity의 구분에 대해서 알아보자.
DAO vs Entity
DAO와 Entity는 둘 다 데이터베이스와 관련된 개념이지만, 서로 다른 역할을 하게 된다. DAO의 역할은 위에서 설명하였으니 Entity에 대해 알아보자면, Entity 역시 같은 Java 객체이지만 DB 테이블과 1:1 매핑되는 객체라는 역할을 부여받았다. 즉, DB 레코드를 표현하는 Java 객체이다. 이 객체는 DB 스키마에 맞게 구성되어 DB 테이블의 각 열을 멤버 변수로 가지며, 각 인스턴스는 데이터베이스의 한 행에 해당한다. 따라서 Entity 객체를 사용하여 DB 레코드를 읽거나 쓰는 등 데이터베이스와의 상호작용을 할 수 있게 된다.
여기서 Entity가 데이터베이스와의 상호작용을 위해 사용된다는 부분이 DAO가 데이터베이스와의 통신을 추상화한다는 것과 어떠한 차이가 있는지는 여전히 불명확할 수 있다. 왜냐하면 많은 우리들은 DAO를 사용해본 경험이 많지 않거나 없을 수 있기 때문이다. 그러니까, 여태껏 우리는 Entity를 통해 데이터베이스와 통신을 잘 해왔는데, 여기에 왜 DAO가 끼어드는지 이해도 안되고 오히려 DAO의 개입이 효율성을 떨어트리는 것이 아니냐는 것이다.
그러나 일반적으로 Entity는 직접적으로 데이터베이스와 통신하지 않는다. 대신 Entity는 DAO를 통해 데이터베이스와의 상호작용을 처리하게 된다. 즉, Entity는 그저 DB 테이블을 1:1 매핑되게 표현한 것이고, 실제 데이터 변경이나 조회 같은 DB 접근은 DAO가 하게 되는 것이다. 오히려 Entity가 직접적으로 데이터베이스와 통신하는 것은 권장되지 않는다.
Entity는 주로 서비스 계층과 리포지토리 계층 사이에서 사용된다. 서비스 계층은 비즈니스 로직을 실행하고, 필요한 경우 데이터 액세스 로직을 호출하여 데이터를 읽거나 쓰기 위해 Entity를 사용하게 되는데, 이러한 데이터 액세스 로직은 일반적으로 리포지토리 패턴을 사용하여 구현된다. 즉, 예전에는 DAO를 많이 사용했었지만, 리포지토리 패턴이나 JPA와 같은 ORM(Object-Relational Mapping) 프레임워크(참고 : [Spring JPA] ORM과 JPA)를 사용함으로써 현재에는 DAO가 사용되지 않는 경우가 많다. 물론 DAO를 사용하거나 사용하지 않는 것은 구현에 따라 다를 수 있지만.
과거에는 DAO를 명시적으로 구현하여 데이터베이스와의 상호작용을 처리하는 것이 일반적이었으나, 최근에는 리포지토리 패턴이나 ORM 프레임워크를 사용하는 것이 더 일반적이게 되었다. 리포지토리는 데이터 액세스 로직을 캡슐화하고, 엔티티와의 상호작용을 추상화하여 제공한다. 그리고 ORM 프레임워크를 사용할 경우, 개발자가 명시적으로 DAO를 구현하지 않아도 된다. ORM 프레임워크가 엔티티와 데이터베이스 간의 매핑을 대신 처리하고, 리포지토리 인터페이스를 통해 데이터 액세스를 추상화한다. 이 과정에서 DAO의 사용이 생략되는 것이다. 그래서 우리가 보기에 데이터베이스에 직접 접근하는 객체는 Entity였던 것처럼 보여진 것이다.
결론
DTO, DAO, Entity가 각각 무엇인지 애매했던 것은 DAO에 대해 알기 어려웠기 때문이다. 그리고 DAO의 존재가 가려지고 그 흔적을 리포지토리 패턴과 ORM 프레임워크가 덮으면서 DTO와 Entity에 대한 이해도 명확하기가 어려웠던 것이다.
개발을 잘 하려면 역사도 알아야 한다.
