DAO, DTO, Repository, Entity Class를 이해하기

일반적으로 스프링 프로젝트 파일에 이름을 정할때, DTO, Repository, Entity 등의 이름이 들어가는 것을 알 수 있는데, 좀 더 자세하게 이 정의에 대해서 알고 싶어졌다.

스프링을 사용한 웹앱의 경우 DAO, DTO, Repository, Entity를 사용하여 데이터를 다루며 스프링부트의 경우 내장 톰캣을 통해 서블릿을 관리하고 이를 컨트롤러에서 각 어노테이션을 통해 매핑한다.

Repository

MVC 패턴에서 모델에 해당하는 부분으로 POJO로는 접근불가능하다.
Persistence Layer와 1:1 매칭이 가능하다.
Java Persistenc API 구현체를 통해서 자바 객체에 접근할 수 있다.

@Repository
@RequiredArgsConstructor
public class MemberRepository {

  private final EntityManager em;

  public void save(Member member) {
    em.persist(member);
  }
}

해당 코드는 JPA 구현체가 Entity Model 객체를 사용해서 DB에 접근한다.

POJO란.

간단하게 설명하자면, "getter / setter를 가진 단순한 자바 오프젝트"이며 의존성이 없고, 테스트도 용이하며 추후 수정이 편리한 오프젝트라고 설명할 수 있을 것 같다/

좀 더 자세하게 설명하면 더 복잡해서 POJO에 대한 글은 다음에 따로 정리하겠다.

DAO(Data Access Object)

원래 DB의 데이터(필드)와 프로그래밍 언어는 패러다임의 불일치로 인해 사용할 수 없다. 이를 원래 사용할려면 별도의 SQL을 작성해서 SQL을 객체의 필드에 하나씩 매핑하거나 순수한 SQL을 작성하여 사용해야 한다.

Entity

하지만 별도의 Entity Class를 사용해서 클래스를 테이블과 1:1 매칭할 수 있다. 이러한 Entity Class를 도메인이라고 하며 가장 DB와 가까운 클래스이다.

@Entity
@Getter
public class Member {
    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id; // PK

    @NotEmpty
    @NotNull
    private String name;

    @Embedded // 내장 타입 임베딩
    private Address address;

    @JsonIgnore
    @OneToMany (mappedBy = "member")
    private List<Order> orders = new ArrayList<>();
}

다음은 예시 코드이다.

Entity의 각 필드는 DB 테이블과 1:1매칭되며 PK를 가진다.
Entity는 순수한 도메인 로직과 비지니스 로직만 가지고 있어야한다.
Entity는 DB의 데이터를 전달해주고 Service에서 사용할 비즈니스 로직만을 가져야한다.

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class MemberService {

    private final MemberRepository memberRepository;

다음 코드는 서비스 계층의 Repository를 사용한 코드이다.

DTO(Data Transfer Object)

Entity를 통해 DB에서 데이터를 꺼내왔지만 데이터를 접근해야하는 경우 문제가 있다.
Controller와 Presentation Layer는 클라이언트와 직접 만나며, Entity는 프레젠테이션 계층과 완전히 분리되어야 한다.
이러한 경우에 DTO를 사용한다.

@Data
@AllArgsConstructor
static class MemberDto {
  private String name;
  private Address address;
}

이러한 경우 다음과 같이 DTO를 사용한다.

특징은 다음과 같다.

Getter/Setter가 없다.
Wrapping 된 순수한 데이터 객체
Entity에 직접 접근하지 않으므로, Entity 변경시, DTO만 변경하면 된다.

결론.

정리하자면 스프링 프로젝트는 다음과 같은 구조를 가진다.

구성은 다음 4개와 같다.

Domain(Entity)

@Entity
@Getter @Setter
public class Member {
    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id;

DB 테이블과 1:1 매칭된다.

Repository(DAO)

@Repository
@RequiredArgsConstructor
public class MemberRepository{

    private final EntityManager em;

Entity를 통해 데이터를 DB에 저장된다.
엔티티는 DB의 데이터와 매칭되는 것
실제 DB에 데이터를 저장하는 건 Repository 클래스의 Entity Manager를 통해 이루어진다

Service

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class MemberService {

    private final MemberRepository memberRepository;

프레젠테이션(뷰)에서 엔티티에 직접 접근하지않고 비즈니스 로직을 처리할 수 있도록하는 계층이다.
Repository에 정의된 비즈니스 로직을 처리하거나 엔티티에 접근한다.

Controller

@RestController // Response + Request
@RequiredArgsConstructor
public class MemberApiController {
    private final MemberService memberService;

    @GetMapping("api/v1/members")
    public Result<List<MemberDto>> memberV2() {

프레젠테이션 계층으로 클라이언트의 요청을 처리한다.
엔티티는 서비스에 의해 추상화되어 직접 접근 불가능하다.
서비스에 정의된 비즈니스 로직을 호출한다.
ResponseBody에 데이터를 담아 반환해준다

출처

# Dto

[Java] DAO, DTO, Repository을 이해하자