[Spring] DAO, DTO, Entity, 기본 계층 설계

 

 

 

 

 

 DTO(Data Transfer Object)

 

 

스프링은 크게 아래의 3가지 계층로 나눠진다.

 

컨트롤러 - 비즈니스 - 데이터  

 

이때 계층 사이에 이동하는 데이터는 항상 같은 클래스를 이용하는 것이 아니다.

실제로 데이터베이스에 저장되는 엔티티 클래스를 모든 계층에서 사용하기 보다는 DTO(Data Transfer Object)로 변환하여 정말 필요한 데이터와 로직만을 담는다.

예를 들어 DTO는 데이터 이동만을 담당하므로 setter와 같은 매서드를 포함시키지 않는 방식이다.

 

아래의 그림 처럼 데이터베이스와 관련이 있다면 Entity로 다루고, 데이터 쪽에서 멀어질 수록 간단한 DTO로 데이터를 다룬다.

 

DTO, Entity 사용 계층

 

 

비즈니스 계층과 데이터 계층간의 데이터 이동은 DTO 또는 Entity를 사용한다.

이는 팀별 업무 규정에 따라 선택하면 된다.

 

단, 이번 게시글에서는 비즈니스 계층과 데이터 계층은 Entity 객체를 통해 데이터를 이동시킨다.

따라서 DTO와 Entity를 변환하는 책임이 비즈니스 계층에 있게 된다.

 

 

 

 

 

DAO (Data Access Object)

 

DAO는 데이터 계층에서 데이터베이스로 접근하는 로직을 담당한다.

spring data JPA에는 엔티티의 Repository를 간단히 만들 수 있지만, 직접 비즈니스 계층이 이를 통해 접근하기에는 세부적인 쿼리 생성이 힘들다. 따라서 DAO 클래스에서 엔티티의 Repository를 주입받아 원하는 쿼리를 만들자.

이러한 중간 계층의 생성은 유지보수 측변에서도 좋고, 비즈니스 계층이 Repository를 직접 호출할 필요가 없어 기능 분리에 효과적이다.

 

글로 설명하는 것보다는 코드를 보는 것이 이해가 빠를 것이다.

 

 

Ingredient Entity

 

 

Ingredient DTO

 

간단하게 Ingredient 라는 엔티티 객체와 대응되는 DTO를 생성하였다.

 

 

 

 

 

 

 

이제 DAO를 만들어 보자.

 

 

(MongoDB JPA 기준)

IngredientRepository

 

 

IngredientDAO (intreface)

스프링의 의존성 주입은 자동으로 구현체를 주입해 주므로 인터페이스와 구현체를 나누어 만들자.

 

 

 

IngredientDAOImpl 구현체

 

DAO Impl에는 repository와 DB(여기서는 MongoDB) template로 원하는 데이터 로직의 구현이 가능하다.

 

 

 

 

 

 

 

 

비즈니스 계층인 Ingredient Service에서는 IngredientDAO를 통해 데이터를 접근하게 설계할 수 있다.

 

 

Ingredient Service

 

이처럼 DTO를 도입하면 Entity 객체의 변화에도 DTO를 사용하는 계층에는 변경없이 코드가 정상 작동한다.

 

단, 반복적인  Entity와 DTO간의 변환이 번거로울 수 있는데, 이를 대신 수행해 주는 것이 MapStruct 라이브러리이다.

이에 대한 자세한 설명과 사용 방법은 다음 게시글에서 진행하겠다.