밑에 적은거 말고도 회사나 개인마다 다르게 로직을 분리할 수 있음
로직을 분리하는 이유
- 구현만 하는거면 route에 라우팅에 비지니스 로직을 모두 적용하면 되지만 그렇게 하면 가독성과 유지보수가 힘들기 때문에 로직을 분리함
알면 좋은거
Express 3계층 설계(3 layer architecture)
- 3 layer architecture는 비즈니스 로직을 분리하는 것을 목적으로 하며 Controller, Service Layer , Data Access Layer 라는 세개의 층으로 나뉩니다.
- controller는 client와의 통신에서 필요한 req, res를 다루는 부분
- service layer은 business logic을 다룬다
- Data Access Layer은 DB와의 직접적인 통신을 다룬다.
계층을 나누는 이유
- 다른 계층에 영향을 주지 않고 특정 계층만 수정, 확장할 수 있습니다.
controller
- 컨트롤러는 들어오는 클라이언트 요청을 받고 서비스에 전달한다.
- 서비스에서 작업을 마친 데이터를 받아 클라이언트에게 응답한다.
service
서비스 계층은 나머지 애플리케이션에서 모든 비즈니스 로직을 캡슐화하고 추상화합니다.
⭕ Service Layer Sould.
- 비즈니스 로직 포함
- 데이터 액세스 계층을 활용하여 데이터베이스와 상호 작용
- controller 계층에 전달할 데이터 리턴
❌ Service Layer Sould Not.
req,res활용- 클라이언트에 대한 응답 처리
- 데이터베이스와 직접 상호 작용
data Access Layer
- 데이터 액세스 계층은 쿼리를 수행하여 데이터베이스와 상호 작용합니다. 제가 사용하고 있는 Sequelize는 Data Access Layer의 역할의 일부를 대체해줍니다.
- sequelize를 사용하지 않으면 아래와 같이 data Access Layer를 담당하는 파일에 쿼리문을 모아서 필요할 때 service 계층에서 호출해서 사용합니다.
로직 나누는 구조
express 프레임워크 기본 폴더 구조
/public
/routes
/views
web.jsrest api 서비스 구조 (spring 프레임워크랑 비슷한거 같기도 하고 아닌거 같기도 하고)
src
│ app.js # App entry point 진입점
└───api # Express route controllers for all the endpoints of the app 엔드포인트에서 라우팅을 하는 부분
└───config # Environment variables and configuration related stuff 환경 변수등 저장하는 폴더
└───jobs # Jobs definitions for agenda.js agenda.js를 사용하는 경우에만
└───loaders # Split the startup process into modules 모듈의 시작점을 적어두는 부분
└───models # Database models DB 모델들
└───services # All the business logic is here 비즈니스 로직을 작성하는 부분
└───subscribers # Event handlers for async task async에 대한 이벤트 핸들러
└───types # Type declaration files (d.ts) for Typescript Typescript 사용하는 경우에만모듈식 코드 구조
├───models
│ ├───user.model.js
├───routes
│ ├───user.route.js
├───services
│ ├───user.service.js
├───controllers
│ ├───user.controller.js모델 - 모델 의 스키마 정의
경로 - API 경로가 컨트롤러에 매핑됩니다.
컨트롤러 - 컨트롤러는 요청 매개 변수 확인, 쿼리, 올바른 코드로 응답 보내기의 모든 로직을 처리합니다.
서비스 - 서비스에는 데이터베이스 쿼리와 반환 객체 또는 오류 발생이 포함됩니다.
