프로젝트를 진행하면서 Controller와 Service, Domain, Repository로 계층을 분류해서 작업을 해왔는데 Dto와 VO, Dao같은 것들이 정확히 무엇인지 개념이 잡히지 않아 계층 구조를 정리하고자 한다.
Controller
- @Controller 사용
- request와 response에 대한 영역을 담당한다.
Service
- @Service 사용
- Controller와 Dao(Repository) 사이에서 사용된다.
Repository
- Dao 영역으로 DB에 접근한다.
- DB 테이블보다 객체 중심의 Layer
- Repository로 다루는 객체를 다루기 위해 여러 Dao(여러 테이블) 사용 가능
- 영속성 객체임을 숨김 (구현체가 인프라 계층에 숨겨져 있음)
- Repository의 인터페이스는 도메인 레이어에 속한다. (객체의 상태를 관리하는 저장소)
repository와 dto는 거의 비슷하면서 다른 느낌이다. repository는 엔티티 객체를 보관, 관리하는 저장소이고 dao는 DB 접근 관련 로직을 모아둔 객체인데 사실 JPA를 사용하면 DB 접근 관련 로직을 알아서 짜줘서.. repository만 사용해도 될 것 같다.
Domain
- @Entity 사용된 영역
- 비즈니스 로직을 처리한다.
- VO도 Domain에 해당된다. (DB의 테이블과 관계가 있는 것만이 도메인은 아님)
Entity
- 실제 DB 테이블과 매핑되는 핵심 클래스
- 요청이나 응답값을 전달하는 클래스로 사용하면 안된다!
- 비즈니스 로직을 포함할 수 있다.
VO (Value Object)
- domain과 다르다.
- 값 그자체를 나타내는 객체
- Dto와 달리 로직을 포함할 수 있고 생성자를 사용해야 함 (불변성 보장)
- 도메인에서 한 개 또는 그 이상의 속성들을 묶어 특정 값을 나타내는 객체
- Entity와 구별해서 사용함
- equals와 hash code 메서드 오버라이딩 해야함 - 필드값이 같으면 같은 객체이기 때문 (주소값으로 비교하면 안된다!)
Dto (Data Transfer Object)
- 계층 간 데이터 교환을 위한 객체
- Repository에서 request를 받기 위해 사용하는 ~Form들이 이곳에 해당한다.
- ex) MemberSaveDto에서 toEntity 함수로 Member Entity를 만들어 분리해줄 수 있다.
- getter/setter(setter 대신 불변성 위해 생성자 사용 가능)만을 갖고 있다. (로직 X)
- 주로 controller와 view 사이에서 데이터 주고 받을 때 활용함
Dao (Data Access Object)
- DB에 접근하는 영역
- Repository가 이 영역에 해당된다.
- 많은 경우에 DAO는 DB 테이블과 일치한다.
- 영속성 객체를 숨기지 않음
