Client → Controller → Service → Repository → DB
Client 와 DB 사이를 세 개의 주요 계층
- Controller
- Service
- Repository
로 분리해 설계한다.
1) Controller
client로부터 들어오는 요청을 처리하는 역할
- Request
Client에게 요청이 오면, Service에게 요청하는 (일을 시키는) 계층, 즉 클라이언트의 요청을 서비스 계층에 전달한다.
- Response
Service계층에서 처리된 결과, 즉 Response를 받아서 적절한 형태로 변환 후 Client에게 되돌려 준다.
→ 이때 응답은 HTML, JSON, XML 등의 Client가 이해할 수 있는 형식!! 으로 전달해야 한다.
2) Service
실질적인 비즈니스 "로직" 일을 하는 계층
-
규칙 및 로직 구현
서비스 계층은 재사용 가능한 비즈니스 로직의 집합으로 구성
예를 들면 고객의 주문을 처리하거나, 재고 관리, 결제 처리 등의 있다.
이런식으로 중복 되는 로직을 서비스 계층에 모아두면 재사용과 유지보수가 용이하다.
-
Repository 계층과의 상호작용
DB에 접근해야 할 일이 있을 때 Repository 계층을 통해 데이터에 접근하고, 이 데이터를 로직에 따라 처리한다.
3) Repository
데이터베이스(DB)와 직접적인 소통하는 역할
다시 말해 Repository 계층은 데이터베이스와 직접 상호작용해 데이터의 CRUD(Create, Read, Update, Delete) 작업을 처리한다.
-
DB 접근
- 데이터 조회 : Application에서 데이터를 필요로 할 때(ex, 상품 조회, 사용자 정보 조회 등) 데이터를 조회한다.
- 데이터 생성 or update : 새로운 데이터를 추가하거나 수정할 때 (ex, 새로운 상품 추가, 상품 정보 수정)
- 데이터 삭제 : 데이터를 제거해야 할 때도 Repository 계층을 통해 접근 한다.
- Service 계층과의 상호작용
앞서 말한 DB에 접근해야 하는 경우는 대부분 서비스 계층에서 로직을 수행하는 동안 필요한 데이터에 접근하거나 변경할 때이다.
- 데이터베이스 독립성
이렇게 Repository 계층일 사용하면, 데이터베이스를 변경하거나 업그레이드 등을 해야 할 때에도 이 Repository 계층의 인터페이스를 유지하면 나머지 부분에 미치는 영향을 최소화 할 수 있다. 또한 데이터 접근하는 로직이 한 곳에 모이기 때문에 유지보수가 용이하다.