데이터 액세스 개체
Data access object소프트웨어에서, 데이터 액세스 객체(DAO)는 어떤 종류의 데이터베이스나 다른 지속성 메커니즘에 추상적인 인터페이스를 제공하는 패턴이다.지속성 계층에 애플리케이션 호출을 매핑함으로써 DAO는 데이터베이스의 세부 정보를 노출하지 않고 일부 특정 데이터 작업을 제공한다.이러한 고립은 단일 책임 원칙을 뒷받침한다.도메인별 객체 및 데이터 유형(DAO의 공개 인터페이스)의 관점에서 애플리케이션에 필요한 데이터 액세스가 어떤 것인지, 이러한 요구를 특정 DBMS, 데이터베이스 스키마 등으로 충족시킬 수 있는 방법(DAO의 구현)을 구분한다.
비록 이 디자인 패턴 균등하게 대부분의 프로그래밍 언어, 소프트웨어의 끈기를 필요로 하는 대부분의 형식 및 데이터베이스의 대부분의 형태에 적용 가능한, 전통적으로 JavaEE애플리케이션과 관계형 데이터베이스와 함께 자세한 내용은 JavaAPI를 통해 접속하는 IT유력 기업인 SunMicrosystems의 최상의 연습의 근원 guidelines[1]"코어 J. 때문에 관련된2EE해당 플랫폼의 "패턴").
이점
데이터 액세스 개체를 사용할 때의 주요 이점은 서로에 대해 알 수는 있지만 서로에 대해 알 수는 없고 자주 그리고 독립적으로 진화할 것으로 예상할 수 있는 애플리케이션의 중요한 두 부분 사이의 비교적 간단하고 엄격한 구분이다.비즈니스 로직의 변경은 동일한 DAO 인터페이스에 의존할 수 있지만, 지속성 로직의 변경은 인터페이스가 올바르게 구현되어 있는 한 DAO 클라이언트에 영향을 미치지 않는다.
저장소의 모든 세부 정보는 응용프로그램의 나머지 부분에 숨겨져 있다(정보 숨기기 참조).따라서, 지속성 메커니즘에 대한 가능한 변경은 애플리케이션의 나머지 부분은 영향을 받지 않는 상태에서 하나의 DAO 구현을 수정하는 것으로 구현될 수 있다.DAO는 애플리케이션과 데이터베이스 사이에서 중개 역할을 한다.그들은 개체와 데이터베이스 기록 사이를 왔다 갔다 한다.단위 시험은 시험에서 DAO를 시험 이중으로 대체하여 시험을 지속성 계층으로부터 독립적으로 만들어 줌으로써 촉진된다.
Java 프로그래밍 언어의 일반적인 맥락에서, 설계 개념으로서의 Data Access Objects는 여러 가지 방법으로 구현될 수 있다.이는 애플리케이션 로직에서 데이터 액세스 부분을 분리하는 상당히 단순한 인터페이스에서 프레임워크 및 상용 제품에 이르기까지 다양하다.DAO 코드화 패러다임에는 약간의 기술이 필요할 수 있다.Java Persistence API와 Enterprise JavaBeans와 같은 기술은 애플리케이션 서버에 내장되어 JavaE 애플리케이션 서버를 사용하는 애플리케이션에서 사용될 수 있다.TopLink와 같은 상용 제품은 ORM(객체 관계 매핑)을 기반으로 사용 가능하며, 인기 오픈 소스 ORM 소프트웨어로는 독트린, 최대 절전 모드, iBATIS, 아파치 오픈JPA와 같은 JPA 구현이 있다.
단점들
DAO를 사용할 때 발생할 수 있는 잠재적인 단점으로는 누출 추상화,[citation needed] 코드 중복, 추상화 반전 등이 있다.특히 DAO를 일반 Java 개체로 추상화하면 각 데이터베이스 액세스에 대한 높은 비용을 숨길 수 있으며, SQL 세트 작업을 사용하여 단일 작업으로 반환될 수 있는 정보를 검색하기 위해 개발자가 다중 데이터베이스 쿼리를 트리거하도록 할 수도 있다.애플리케이션에 여러 DAO가 필요한 경우 각 DAO에 대해 기본적으로 동일한 코드 생성, 읽기, 업데이트 및 삭제를 반복하는 자신을 발견할 수 있다.그러나 이러한 공통 작업을 처리하는 일반 DAO를 구현하면 이러한 보일러 판 코드를 피할 수 있다.[2]
가상 사용 시나리오
당신이 두 명의 다른 고객들을 위한 어플리케이션을 개발하는 계약을 받은 성공적인 회사를 소유하고 있는 상황을 상상해보라.신청서의 사양은 두 고객에 대해 거의 동일하다.두 클라이언트 모두 SQL 데이터베이스를 사용하여 데이터를 관리하지만, 한 회사는 독점 데이터베이스를 사용하고 다른 회사는 오픈 소스 대안을 사용하므로, 애플리케이션의 지속성 계층을 두 가지 다른 방법으로 구현해야 할 필요가 있다.또한 새로운 클라이언트가 생겨나면서 추가적인 구현이 필요할 수 있다.이 경우 Data Access Object 패턴을 사용하면 다양한 백엔드 데이터베이스에 액세스하는 데 필요한 적절한 양의 추상화 및 캡슐화를 보장할 수 있다.
도구 및 프레임워크
- C++용 ODB 컴파일러 기반 ORM(개체 관계 매핑) 시스템
- ORMLite: JDBC 및 Android용[3] Java의 ORM(경량 객체 관계 매핑) 프레임워크
- 마이크로소프트 엔티티 프레임워크
- DBIx:Perl용 ORM(Class Object-Relational Mapping) 모듈
- TuxORM: JDBC용 Java의 ORM(단순 객체 관계 매핑) 라이브러리
참고 항목
- 생성, 읽기, 업데이트 및 삭제(CRUD)
- 데이터 액세스 계층
- 서비스 데이터 개체
참조
- ^ "Core J2EE Patterns - Data Access Objects". Sun Microsystems Inc. 2007-08-02.
- ^ 해결 방법은 http://www.ibm.com/developerworks/java/library/j-genericdao/index.html을 참조하십시오.
- ^ Hodgson, Kyle; Reid, Darren (2015-01-23). ServiceStack 4 Cookbook. Packt Publishing Ltd. p. Chapter 4. ISBN 9781783986576. Retrieved 22 June 2016.