데이터 접근 객체
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
데이터 접근 객체(DAO)는 애플리케이션에서 데이터 접근을 위한 추상화 계층을 제공하는 디자인 패턴이다. DAO는 애플리케이션의 다른 부분과 데이터 저장소 간의 의존성을 분리하여, 비즈니스 로직의 변경 없이 데이터 접근 방식을 쉽게 변경할 수 있도록 한다. DAO의 장점으로는 코드의 재사용성과 유지보수 용이성, 유닛 테스트의 용이성, 정보 은닉 등이 있으며, 자바를 포함한 다양한 프로그래밍 언어에서 구현될 수 있다. 단점으로는 추상화 누수, 코드 중복, 추상화 반전 등이 있을 수 있다. 데이터 접근 객체를 구현하기 위한 다양한 도구와 프레임워크가 존재한다.
더 읽어볼만한 페이지
- 아키텍처 패턴 - 서비스 지향 아키텍처
서비스 지향 아키텍처(SOA)는 기능들을 독립적인 서비스 단위로 분리하여 느슨하게 결합함으로써, 네트워크를 통해 접근 가능한 서비스를 재사용하고 결합하여 응용 프로그램을 구축하는 소프트웨어 아키텍처이다. - 아키텍처 패턴 - 제어 반전
제어 반전은 프로그램의 제어 흐름을 프레임워크나 컨테이너가 관리하도록 하는 프로그래밍 원칙으로, 코드 결합도를 낮추고 유연성을 높이지만, 복잡성을 증가시킬 수 있다는 비판도 존재한다. - 소프트웨어 디자인 패턴 - 모델-뷰-컨트롤러
모델-뷰-컨트롤러(MVC)는 소프트웨어 디자인 패턴으로, 응용 프로그램을 모델, 뷰, 컨트롤러 세 가지 요소로 분리하여 개발하며, 사용자 인터페이스 개발에서 데이터, 표현 방식, 사용자 입력 처리를 분리해 유지보수성과 확장성을 높이는 데 기여한다. - 소프트웨어 디자인 패턴 - 스케줄링 (컴퓨팅)
스케줄링은 운영 체제가 시스템의 목적과 환경에 맞춰 작업을 관리하는 기법으로, 장기, 중기, 단기 스케줄러를 통해 프로세스를 선택하며, CPU 사용률, 처리량 등을 기준으로 평가하고, FCFS, SJF, RR 등의 알고리즘을 사용한다.
| 데이터 접근 객체 | |
|---|---|
| 기본 정보 | |
 | |
| 유형 | 디자인 패턴 |
| 목적 | 데이터 소스 접근 로직 캡슐화 |
| 솔루션 | 데이터 소스 접근 구현 분리 |
| 참여자 | 데이터 접근 객체 (DAO) 인터페이스 구체적인 데이터 접근 객체 데이터 전송 객체 (DTO) |
| 개요 | |
| 문제 | 응용 프로그램이 데이터 소스에 직접 접근하는 경우, 데이터 소스 변경 시 응용 프로그램 코드 수정 필요 |
| 해결책 | 데이터 접근 로직을 별도의 객체 (DAO)로 캡슐화하여 응용 프로그램과 데이터 소스 간의 결합도 감소 |
| 장점 | 데이터 소스 변경에 대한 응용 프로그램의 독립성 유지 코드 재사용성 향상 테스트 용이성 증가 |
| 단점 | 추가적인 클래스 및 인터페이스 생성으로 인한 복잡성 증가 |
| 구조 | |
| 데이터 접근 객체 (DAO) 인터페이스 | 데이터 접근 작업을 위한 표준 인터페이스 정의 |
| 구체적인 데이터 접근 객체 | 특정 데이터 소스에 대한 실제 접근 로직 구현 |
| 데이터 전송 객체 (DTO) | 데이터 소스 간 데이터 전송을 위한 객체 |
| 구현 | |
| 단계 | 데이터 접근 객체 인터페이스 정의 데이터 접근 객체 구현 클래스 생성 데이터 전송 객체 클래스 생성 응용 프로그램에서 데이터 접근 객체 사용 |
| 예시 | |
| 자바 | Core J2EE Patterns - Data Access Objects (Oracle) |
2. 장점
데이터 접근 객체(DAO)를 사용하는 핵심적인 장점은 애플리케이션의 주요 구성 요소인 비즈니스 로직과 데이터 영속성 처리 로직을 명확하게 분리할 수 있다는 점이다.[2][3] 이러한 분리는 각 부분이 서로의 내부 구현에 대해 알 필요 없이 독립적으로 개발되고 수정될 수 있는 환경을 제공한다. 즉, 비즈니스 규칙이 변경되더라도 데이터 접근 방식에 영향을 주지 않으며, 반대로 데이터 저장 기술이나 스키마가 변경되어도 비즈니스 로직은 영향을 받지 않는다.
또한, DAO 패턴은 데이터 저장과 관련된 구체적인 세부 사항들을 애플리케이션의 나머지 부분으로부터 숨기는 정보 은닉 원칙을 적용한다. 이는 코드의 복잡성을 낮추고, 유닛 테스트 시 실제 데이터베이스 대신 테스트 더블을 사용하여 테스트를 용이하게 만드는 부가적인 이점도 제공한다.
이 디자인 패턴은 특정 프로그래밍 언어나 데이터베이스 기술에 국한되지 않고 다양한 환경에서 활용될 수 있다. 특히 자바 환경에서는 JDBC, JPA, Hibernate 등 다양한 영속성 기술로부터 애플리케이션의 핵심 로직을 효과적으로 분리하는 데 널리 사용된다.[4] 결과적으로 DAO를 사용하면 기술 변화에 유연하게 대처하고 시스템 전체의 유지보수성을 향상시킬 수 있다.
2. 1. 개발 및 유지보수의 용이성
데이터 접근 객체(DAO)를 사용하면 애플리케이션의 비즈니스 로직과 데이터 영속성 처리 로직이라는, 서로 알 필요가 없는 두 부분을 명확하게 분리할 수 있다는 장점이 있다.[2][3] 이 분리 덕분에 각 부분은 상대방의 변경에 영향을 덜 받으며 독립적으로 개발하고 수정할 수 있다. 예를 들어, 비즈니스 로직이 변경되더라도 일관된 DAO 인터페이스를 통해 데이터 접근이 가능하며, 반대로 데이터 저장 방식이나 데이터베이스 스키마 같은 영속성 로직의 세부 사항이 변경되어도 DAO를 사용하는 클라이언트 코드(주로 비즈니스 로직)는 영향을 받지 않는다.[2][3]DAO는 모든 저장 관련 세부 정보를 애플리케이션의 나머지 부분으로부터 숨기는 정보 은닉 원칙을 따른다. 또한, 유닛 테스트 시 실제 데이터베이스 대신 테스트 더블(Test Double)로 DAO를 대체하여 테스트를 용이하게 만들며, 이를 통해 영속성 계층과 독립적인 테스트 수행이 가능하다.
결과적으로 DAO 패턴은 애플리케이션이 어떤 데이터 접근을 필요로 하는지(DAO의 공개 인터페이스 정의)와, 해당 요구사항을 특정 DBMS나 데이터베이스 스키마를 사용하여 어떻게 충족시킬 것인지(DAO의 구체적인 구현)의 문제를 분리한다.
이 디자인 패턴은 다양한 프로그래밍 언어와 데이터베이스 환경에서 활용될 수 있다. 특히 자바 환경에서는 썬 마이크로시스템즈(Sun Microsystems)의 모범 사례 가이드라인[7]("Core J2EE Patterns")에서 유래되어, 자카르타 EE 애플리케이션이 JDBC API를 통해 관계형 데이터베이스에 접근할 때 널리 적용된다. 자바에서는 DAO를 통해 JDBC, JDO, EJB CMP, JPA, TopLink, Hibernate, iBATIS 등 다양한 자바 영속성 기술로부터 애플리케이션 본체를 격리할 수 있다.[4] 이를 통해 기반이 되는 영속성 기술을 업데이트하거나 교체하더라도 애플리케이션의 다른 부분을 변경할 필요가 없어 유지보수가 용이해진다.
2. 2. 정보 은닉
데이터 접근 객체(DAO)를 사용하면 애플리케이션에서 비즈니스 로직과 데이터 접근 로직이라는 중요한 두 부분을 명확하게 분리할 수 있다는 장점이 있다. 이러한 분리는 각 부분이 서로에 대해 거의 알 필요 없이 독립적으로 발전하고 수정될 수 있게 한다. 예를 들어, 비즈니스 로직이 변경되더라도 일관된 DAO 인터페이스에 의존할 수 있으며, 반대로 데이터베이스 기술이나 저장 방식 같은 영속성 로직의 수정은 DAO를 사용하는 클라이언트에 영향을 미치지 않는다.[2][3]모든 저장 관련 세부 정보는 애플리케이션의 나머지 부분으로부터 숨겨지는데, 이를 정보 은닉이라고 한다. 정보 은닉 덕분에 유닛 테스트를 더 쉽게 할 수 있다. 테스트 과정에서 실제 DAO 대신 테스트 더블을 사용하여 영속성 계층과 독립적으로 테스트를 진행할 수 있다.
데이터 접근 객체는 문제를 두 부분으로 나눈다. 첫째는 애플리케이션에 어떤 데이터 접근이 필요한지에 대한 정의(DAO의 공개 인터페이스)이며, 이는 도메인 고유 객체와 데이터 형식을 사용한다. 둘째는 이러한 요구사항을 특정 DBMS나 데이터베이스 스키마를 사용하여 어떻게 충족시킬 것인지에 대한 구현(DAO의 구현)이다.
이 디자인 패턴은 많은 프로그래밍 언어에서 사용할 수 있으며, 영속성이 필요한 많은 애플리케이션이나 여러 종류의 데이터베이스에서 활용될 수 있다. 그러나 이 패턴은 썬 마이크로시스템즈(Sun Microsystems)의 모범 사례 가이드라인[7]("Core J2EE Patterns")에서 유래되었기 때문에, 주로 자바 환경에서 JDBC API를 통해 자카르타 EE 애플리케이션이 관계형 데이터베이스에 접근할 때 적용되는 경우가 많다.
자바 프로그래밍 언어의 맥락에서 DAO는 다양한 방식으로 구현될 수 있다. 이는 데이터 접근을 애플리케이션 로직에서 분리하는 상당히 간단한 인터페이스에서부터 프레임워크 및 상용 제품에 이르기까지 다양하다. 자바 퍼시스턴스 API 및 엔터프라이즈 자바빈과 같은 기술은 애플리케이션 서버에 내장되어 있으며, 자바 EE 애플리케이션 서버를 사용하는 애플리케이션에서 사용될 수 있다. TopLink와 같은 상용 제품은 객체-관계 매핑(ORM)을 기반으로 사용할 수 있다. 널리 사용되는 오픈 소스 ORM 소프트웨어로는 Doctrine, Hibernate, iBATIS, 그리고 Apache OpenJPA와 같은 JPA 구현이 있다.[4] 자바에서는 다양한 자바 영속성 기술들(JDBC, JDO, EJB CMP, TopLink, Hibernate, iBATIS 등)로부터 애플리케이션 본체를 격리하기 위해 데이터 접근 객체를 사용한다.
2. 3. 테스트 용이성
데이터 접근 객체(DAO)를 사용하면 데이터 저장과 관련된 세부 사항을 애플리케이션의 나머지 부분으로부터 숨길 수 있다(정보 은닉 참조). 이는 유닛 테스트를 용이하게 만드는 중요한 장점이다. 테스트 과정에서 실제 데이터베이스에 접근하는 DAO 대신 테스트 더블을 사용함으로써, 테스트 코드는 영속성 계층과 완전히 분리되어 독립적으로 실행될 수 있다. 즉, 데이터베이스 연결이나 상태에 영향을 받지 않고 비즈니스 로직의 정확성을 검증하는 것이 가능해진다.2. 4. 다양한 구현 방식 (자바 환경)
자바 프로그래밍 언어 환경에서 데이터 접근 객체(DAO)는 다양한 방식으로 구현될 수 있다. 이는 데이터 접근 로직을 애플리케이션 로직에서 분리하는 비교적 간단한 인터페이스 설계에서부터, 다양한 프레임워크나 상용 제품을 활용하는 방식에 이르기까지 다양하다.구체적인 구현 기술로는 자바 퍼시스턴스 API(JPA)나 엔터프라이즈 자바빈(EJB) 등이 있으며, 이는 자카르타 EE 애플리케이션 서버에 내장되어 활용될 수 있다. 또한 객체-관계 매핑(ORM) 기술을 기반으로 한 TopLink와 같은 상용 제품이나, Hibernate, iBATIS, Apache OpenJPA (JPA 구현체 중 하나) 등 널리 사용되는 오픈 소스 ORM 소프트웨어를 이용할 수도 있다.[4]
DAO 패턴의 핵심 장점은 애플리케이션의 비즈니스 로직과 데이터 영속성 로직이라는 중요한 두 부분을 명확하게 분리[2][3]하여 서로에게 미치는 영향을 줄이고 독립적으로 개발 및 수정할 수 있게 한다는 점이다. 이를 통해 JDBC, JDO, EJB CMP 등 다양한 자바 영속성 기술로부터 애플리케이션의 핵심 로직을 격리할 수 있으며, 기반 데이터 저장 기술을 변경하거나 업데이트하더라도 애플리케이션의 다른 부분을 수정할 필요가 거의 없어진다. 이러한 분리는 유닛 테스트도 용이하게 만드는데, 테스트 시 실제 데이터베이스 대신 테스트 더블을 사용하여 영속성 계층과 독립적인 테스트 수행이 가능하다.
이 패턴은 본래 썬 마이크로시스템즈(Sun Microsystems)의 모범 사례 가이드라인[7]("Core J2EE Patterns")에서 소개되었으며, 특히 자카르타 EE 환경에서 JDBC API를 통해 관계형 데이터베이스에 접근하는 경우에 주로 적용되어 왔다.
3. 단점
데이터 접근 객체(DAO)를 사용하는 데에는 몇 가지 잠재적인 단점이 존재한다. 주요 문제점으로는 누수 추상화, 코드 중복, 그리고 추상화 반전 등이 거론된다.[5] 예를 들어, 데이터베이스 접근에 드는 실제 비용이 추상화 뒤에 가려지거나, 여러 DAO에서 유사한 코드가 반복될 수 있다.
이러한 단점들은 특히 각 데이터베이스 테이블마다 별도의 DAO를 생성하고, SELECT 쿼리가 해당 테이블 외에는 접근하지 못하도록 제한하는 경우에 더욱 두드러질 수 있다.[5]
3. 1. 추상화 누수
데이터 접근 객체(DAO) 사용의 잠재적인 단점으로는 누수 추상화, 코드 중복, 그리고 추상화 반전 등이 있다. 특히, DAO를 일반적인 자바 객체로 추상화하면 각 데이터베이스 접근의 높은 비용을 가릴 수 있다. 개발자는 실수로 단일 작업으로 반환될 수 있는 정보를 가져오기 위해 여러 데이터베이스 쿼리를 수행할 수 있다. 애플리케이션에 여러 DAO가 필요한 경우, 각 DAO에 대해 동일한 생성, 읽기, 업데이트 및 삭제 코드를 작성해야 할 수 있다.[5]이러한 단점은 각 테이블에 대해 별도의 DAO가 있고 SELECT 쿼리가 대상 테이블 외에는 어떤 것에도 접근하지 못하도록 할 때만 나타난다.
3. 2. 코드 중복
데이터 접근 객체(DAO) 사용 시 발생할 수 있는 문제점 중 하나는 코드 중복이다. 애플리케이션에 여러 DAO가 필요한 경우, 각 DAO마다 비슷한 생성(Create), 읽기(Read), 업데이트(Update), 삭제(Delete) 코드를 반복해서 작성해야 할 수 있다.[5] 이러한 코드 중복은 특히 각 데이터베이스 테이블마다 별도의 DAO를 만들고, SELECT 쿼리가 해당 테이블 외의 다른 테이블에는 접근하지 못하도록 제한할 때 더 두드러지게 나타난다.3. 3. 추상화 반전
데이터 접근 객체(DAO) 사용의 잠재적인 단점으로는 누수 추상화, 코드 중복, 그리고 추상화 반전 등이 있다. 특히, DAO를 일반적인 자바 객체처럼 단순하게 사용하도록 만들면, 실제로는 데이터베이스에 접근하는 데 드는 높은 비용(시간과 자원)이 잘 드러나지 않을 수 있다. 이 때문에 개발자가 데이터베이스에서 한 번의 쿼리로 가져올 수 있는 정보를 여러 번의 쿼리로 나누어 가져오는 실수를 할 수도 있다.또한, 애플리케이션에 여러 종류의 DAO가 필요할 때, 각각의 DAO마다 비슷한 기능(데이터 생성, 읽기, 수정, 삭제 등)을 하는 코드를 반복해서 작성해야 하는 코드 중복 문제가 발생할 수도 있다.[5]
이러한 문제점들은 주로 각 데이터베이스 테이블마다 별도의 DAO를 만들고, SELECT 쿼리가 해당 테이블의 정보만 가져오도록 제한될 때 더 두드러지게 나타난다.
4. 도구 및 프레임워크
참조
[1]
웹사이트
Core J2EE Patterns - Data Access Objects
http://www.oracle.co[...]
Sun Microsystems Inc.
2007-08-02
[2]
웹사이트
Data Access Object(DAO) Design Pattern
https://www.digitalo[...]
2024-07-08
[3]
웹사이트
Data Access Object(DAO) Design Pattern
https://www.geeksfor[...]
2024-07-08
[4]
웹사이트
Data Access Object(DAO) Design Pattern
https://www.geeksfor[...]
2024-01-29
[5]
문서
http://www.ibm.com/d[...]
[6]
서적
ServiceStack 4 Cookbook
https://books.google[...]
Packt Publishing Ltd
2016-06-22
[7]
웹사이트
Core J2EE Patterns - Data Access Object
https://www.oracle.c[...]
Sun Microsystems Inc.
2007-08-02
[8]
웹인용
Core J2EE Patterns - Data Access Objects
http://www.oracle.co[...]
Sun Microsystems Inc.
2007-08-02
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com