[Springboot] DAO 설계

DAO : 데이터베이스에 접근하기 위한 로직을 관리하기 위한 객체 (데이터 조작 기능)

 

스프링 데이터 JPA에서 DAO의 개념은 리포지토리가 대체!! 

 

비즈니스로직을 개발 하다보면 데이터를 다루는 중간 계층을 두는 것이 유지보수 측면에서 용이한 경우가 많음. 

 

DAO 클래스 생성

DAO 클래스는 일반적으로 '인터페이스-구현체' 구성으로 생성함. 

서비스레이어에 DAO객체를 주입받을 때 인터페이스를 선언하는 방식으로 구성할 수 있음. 

import com.springboot.jpa.data.entity.Product;

public interface ProductDAO {

    // method 선언
    Product insertProduct(Product product); // 새로운 값 입력 시 사용, REST : POST
    Product selectProduct(Long number);     // 특정 번호를 조회, REST : GET
    Product updateProduct(Long number, String name) throws Exception; // 특정 번호로 상품 명 수정, REST :  PUT
    void deleteProduct(Long number) throws Exception; // REST : DELETE

}

왜 dao는 인터페이스 - 구현체 구성으로 생생할까? 

- 가장 큰 이유는 의존성 결합을 낮추기 위해서이다. 

: 의존성 결합이란, 한요소가 다른 요소에 얼마나 의존하는지를 나타낸다. 높은 의존성 결합은 코드를 변경해야할 때 어려움을 줄 수 있다. 

 

- 인터페이스는 클래스가 구현해야하는 메서드의 명세를 정의하는데 이메서드들은 어떤 동작을 수행하는지만 설명하고 실제 구현 내용은 제공하지 않는다. 따라서 변경사항이 생겼을 경우에는 인터페이스만 수정하면 된다. 또한 구현체는 실제로 인터페이스에서 정의한 메서드들을 구현하는 역할을 한다. 이 구현체들은 인터페이스의 메서드를 자신의 비즈니스 논리와 데이터 엑세스 코드로 구체화한다. 

 

- 유연성 및 확장성 : DAO인터페이스를 정의하면 다양한 구현체를 만들 수 있다. 예를들어 다른 데이터 베이스를 사용하는 경우 데이터 베이스에 대한 각각의 다른 데이터 소스를 인터페이스 수정없이 구현체만 수정할 수 있다. 

- 테스트 용이성 : 인테페이스와 구현체를 분리하면 테스트에 용이하다. Mock객체를 활용하여 DAO인터페이스의 구현체를 대체할 수 있으므로 단위테스트 수행 시 데이터베이스 연결을 필요로하지 않는다. 

- 의존성 분리 : 서비스 클래스가 데이터 접근 기술에 대해 알 필요가 없으며 유지보수와 테스트가 더 쉬워짐. 

 

 

빌더 메서드 

: 빌더 패턴을 따르는 메서드이다. 데이터 클래스를 사용할 때 생성자로 초기화할 경우 모든 필드에 값을 넣거나 null을 명시적으로 사용해야 함. 이러한 단점을 보완하기 의해 나온 빌더 패턴. 이 패턴을 이용하면 필요한 데이터만 설정할 수 있어 유연성을 확보할 수 있다.