DAO DTO / VO

📌 DAO

---

💡 DAO (Data Access Object)
- DB의 data에 접근하기 위한 객체로 직접 DB에 접근하여 데이터를 삽입, 삭제, 조회 등 조작할 수 있는 기능을 수행

• 실제로 DB에 접근하는 객체

 

등장 배경

애플리케이션에서 데이터베이스(MySQL, Oracle, … 등)에 접근하기 위해서는 각 벤더에서 제공하는 API를 통해서 접근하면 된다.

 

⚠️ 하지만, 이런 방법에는 문제가 존재

 

1. 구현체와 로직에 강한 결합이 생긴다.
   • DB로 MySQL를 사용하고 있었다고 가정했을 때, DB를 Oracle로 바꿔야 하는 요구사항이 생기면 MySQL의 API를 사용한 모든 로직을 Oracle의 API를 사용하도록 변경해야 한다
   • 이는 변경에 자유롭지 못하는 문제를 가진다 - OCP 위반
2. 레이어가 깨짐
   • 표현계층 - presentation
   • 응용계층 - application
   • 도메인 - domain
   • 인프라 - infrastructure
   • 이런 계층 구조에서 영속성 레이어는 인프라 스트럭처에 속해있다.
   • 하지만 MySQL의 API를 서비스로직에서 사용하기 위해서 application 계층에서 API를 생성했다면 appliction을 담당하는 객체와 DB와 관련된 API가 강한 결합을 가지게 된다.
   • 이로 인해 영속성과 관련된 로직이 서비스 로직에 생성되면서 인프라와 응용계층이 섞인다.
3. 사용 시 어려움
   • 벤더사마다 사용하는 API가 같을 수가 없다.
   • 따라서 개발자는 새로운 벤더의 API를 사용할 때마다 학습을 해야 한다.

 

이런 문제점들을 해결하기 위해 나온 것이 DAO이다.

 

❗ DAO는 벤더들의 API와 비즈니스 로직 사이에 있는 어댑터 같은 역할을 한다.

• DAO 패턴을 적용할 때는 인터페이스와 구현 클래스를 분리해야 한다.
• DAO 인터페이스는 데이터 엑세스 로직만을 정의하도록 한다 ⇒ 레이어 간 결합도를 낮추는 것이 중요

 

🔍 Mybatis

💡 Mybatis는 자바 오브젝트와 SQL 사이의 자동 매핑 기능을 지원하는 SQL 매핑 프레임워크이다.

 

📖 SQL 매핑 프레임워크

• 객체와 관계형 데이터베이스 간의 매핑을 처리하는 기술
• 개발자가 SQL 쿼리를 직접 작성하지 않고도 데이터베이스와 상호 작용할 수 있게 해 준다.
• SQL 쿼리와 데이터베이스 스키마를 객체 모델에 매핑하는 기능을 제공한다.

 

Mybatis

• SQL을 별도의 파일로 분리해 관리하게 해준다. ( XML 파일 )
  • 이로 인해 SQL 쿼리와 DAO 코드를 분리해 유지 보수성을 향상시키며, 복잡한 SQL 쿼리를 처리하는데 특히 효과적이다.

 

• JPA(Hibernate)처럼 새로운 DB 프로그래밍 패러다임을 익혀야 하는 부담 없이 SQL을 그대로 이용하면서 JDBC 코드 작성의 불편함도 제거해 주고 도메인 객체나 VO 객체를 중심으로 개발이 가능하다.

 

Mybatis는 Data Access Layer에서 사용하는 프레임워크이다.

Controller에서 Service를 호출하고 Service가 DAO 계층에 있는 메서드를 호출하면 DAO에서 Mybatis를 호출한다.

 

왜 사용❓

1. 데이터베이스와의 분리
   • DAO를 사용하면 데이터베이스와의 상호작용 코드를 모듈화해 데이터베이스와의 결합도를 낮출 수 있다.
   • 유지보수성 ⬆️
   • 다양한 데이터베이스 시스템과의 호환성 ⬆️
2. 코드 재사용
   • 데이터베이스와의 상호작용 코드를 모듈화해 코드의 재사용성 ⬆️
3. 보안성
   • DAO 사용 시 데이터베이스와의 연결 정보를 DAO 객체 내부에 저장할 수 있다.
     • 외부에서 이 정보를 볼 수 없다.
     • ex) 데이터베이스 접근을 위한 사용자 이름, 비밀번호 등
   • 보안성 ⬆️, 데이터베이스 접근을 제어할 수 있다.
4. 단위 테스트 용이
   • DAO는 인터페이스와 구현 클래스로 구성되어 단위테스트를 쉽게 수행할 수 있다.
   • 인터페이스를 구현한 가짜 객체를 만들어 단위 테스트를 수행할 수 있다.
5. 객체지향적인 설계
   • DAO 객체는 데이터베이스와의 상호작용을 캡슐화한다.

 

📖 DAO 객체

• DAO 객체는 데이터베이스와 상호작용을 수행하는 객체
• 데이터베이스와의 연결을 관리하고 데이터베이스에 쿼리를 전달하고 결과를 반환
• 즉, 데이터베이스와의 상호작용을 추상화한 인터페이스 역할을 한다.

🆚 Entity

• Entity는 데이터베이스에서 가져온 데이터를 나타내는 객체
• 하나의 데이터베이스 테이블에 대응된다. ( 데이터베이스 레코드를 객체로 나타낸 것 )

DAO 객체에서는 데이터베이스에서 데이터를 가져와 Entity 객체로 매핑 후, 이를 반환

 

⭐ Repository와 DAO

repository := dao (유사)

 

DAO, Repository 모두 데이터를 영구 저장소에서 가져오고 조작하는 데 사용되는 패턴이다.

 

📖 dao

• 데이터베이스와 직접 상호작용하는 객체
• 데이터베이스 연결, 쿼리 작성 및 결과 처리와 같은 로우 레벨의 작업을 처리
• 데이터에 접근하도록 DB접근 관련 로직을 모아둔 객체

 

📖 repository

• DAO 보다 더 추상적
• 데이터에 대한 추상 레이어를 제공하며, 데이터베이스의 구체적인 구현과 분리된다.
• 데이터에 대한 인터페이스를 제공해 이를 통해 데이터에 대한 접근을 관리하고 도메인 논리와 분리해 유지 보수성을 향상시킨다.
• Repository는 도메인 모델을 쿼리 하는 데 사용되는 쿼리 객체를 제공해 도메인 객체가 데이터베이스에 직접 알 수 없도록 한다
• 엔티티 객체를 보관하고 관리하는 저장소
• 도메인 정보를 가지고 있어야 하므로 인프라 계층이 아닌 도메인 계층이어야 한다.

 

정리

DAO는 데이터베이스와 직접 상호 작용하는 객체

Repository는 데이터 엑세스에 대한 추상적인 레이어를 제공하는 객체

 

📌 DTO

---

💡 DTO (Data Transfer Object)
 - DTO는 계층간(Controller, View, Business Layer) 데이터 전송을 목적으로 하는 객체 

 

특징

• 비즈니스 로직을 가지지 않는다.
  • Getter / Setter 메서드만 가진 클래스를 의미
• 일반적으로 여러 개의 필드로 구성

 

사용하는 경우

• 서로 다른 시스템(계층) 간에 데이터를 전송하기 위해 사용
  • ex) 클라이언트 ←→ 서버
  • ex) Presentation Layer ←→ Application Layer

 

계층 간 데이터를 전송할 때 DTO는 데이터를 캡슐화하고, 이를 통해 데이터의 무결성과 보안성을 유지할 수 있다.

 

📌 VO

---

💡 VO (Value Object)
 - DTO와 달리 VO는 Read-Only 속성을 가지는 값 오브젝트이다 

특징

• 비즈니스 로직을 가지는 객체
  • 비즈니스 로직을 처리하는 메서드를 포함할 수 있다.
• 일반적으로 불변(immutable)하게 설계된다.
  • setter 메서드를 제공하지 않는다.
  • getter 메서드만을 제공한다.

 

사용되는 경우

• VO는 일반적으로 도메인 모델의 일부로 사용된다.
  • 도메인 모델에서 값을 전달하는 데 사용

 

참고자료

https://velog.io/@ha0kim/DAO-DTO-VO-차이

https://velog.io/@maketheworldwise/DAO와-Repository의-차이

https://bbbicb.tistory.com/44