Controller
주로 사용자의 요청을 처리한 후 지정된 뷰에 모델 객체를 넘겨주는 역할로
사용자의 요청이 진입하는 지점으로 요청에 따라 어떤 처리를 할지 결정을 Service에 넘겨줌
; Client의 요청을 받았을 때 그 요청에 대해 실제 업무를 수행하는 Service를 호출하고
- 클라이언트가 보낸 데이터가 있다면 호출 시 전달하기 쉽게 데이터 가공
모델의 업무 수행이 완료되면 그 결과를 바탕으로 화면을 구성하도록 View에 전달함
Service
비즈니스 로직을 수행하고 DB에 접근하는 DAO를 이용해서 결과값을 받아 와 처리한 내용을 View에 넘겨줌
; Controller의 요청을 받아 알맞은 정보를 가공하여 Controller에게 재전달
- Repository를 상속받아 관련 함수 사용이 가능
DAO (Data Access Object)
DB에 접근하기 위한 객체
-
영속성 객체를 숨기지 않음; 구현체가 인프라 계층에 있다는 것을 숨기지 않음
-
서비스와 DB를 연결하기 위한 중간 다리
-
JPA는 매우 적은 코드로 DAO를 구현할 수 있도록 해줌
Repository
DB에 접근하기 위한 객체이자 객체의 상태를 관리하는 저장소로 영구 저장소가 아닌 객체의 상태를 관리하는 저장소
; Entity에 의해 생성된 DB에 접근하는 메서드를 사용하기 위한 인터페이스
- 인프라 계층이 아니라 도메인 계층
- 영속성 객체임을 숨김; 구현체가 인프라 계층에 숨겨져 있음
- JPA를 상속받음으로써 기본적인 CRUD 동작이 가능해짐
DTO (Data Transfer Object)
계층(Layer)간 데이터 교환을 위해 사용하는 객체
-
데이터 교환만을 위해 사용하므로 로직을 가지지 않고, getter/setter 메소드만 갖는다.
-
뷰에서 컨트롤러로 넘어오는 데이터를 담거나, 컨트롤러에서 서비스로 넘기는 데이터를 담거나 할 때 사용
Entity (Domain)
DB 테이블 내에 존재하는 Column만을 속성(field)로 가지는 클래스
; DB 테이블과 매핑되며 실제 DB에 저장되는 내용들을 구현하는 class (Entity Table)
- PK (id)로 구분
- 상속을 받거나 구현체여서는 안됨
- Setter를 사용하면 안됨
- 로직을 가질 수 있음
DB
VO (Value Object)
값 그 자체를 표현하는 객체
- 로직을 포함할 수 있음
- 객체의 불변성을 보장함; 객체의 정보가 변경되지 않음
+ Practice
Qvest의 oms 프로젝트 중 백엔드 task인 help.oms API를 개발하게 되면서 알게 된 점을 간단하게나마 정리한다.
CRUD 기반 REST API를 Spring으로 구현한 일반적인 형태는 다음 실습 참고 Github 소스를 참고하면 좋을 것 같다.
Entity, DTO, Repository, Service, Controller(아래 소스에서는 Resource)를 비교적 잘 구분해놓았기 때문에 각각의 개념과 쓰임을 익히는데 도움이 될 것 같다.
다만 해당 코드가 이번 task를 진행하면서 Abstraction을 좀 더 잘 지키기 위해 작성한 코드와 조금 다른 건, Service에 대해 Service Interface와 Service 하위 Package로 Implementation(ServiceImpl)이 존재하지 않고 바로 Service Class를 구현하였다는 점 정도인 것 같다.
Ref
