이번 글에서는 백엔드 개발에서 기본적으로 사용되고 있는 Repository, Service, Controller를 정리해보고자 한다. 일반적으로 다들 이러한 패턴을 사용하니까 사용했던게 커서 정리를 하려고 한다.
Repository, Service, Controller 이 셋을 각자 명확한 역할을 가지고 있기 때문에 애플리케이션의 구조와 유지보수성을 향상시키는 데 도움이 된다.
🕹️ Repository: 데이터베이스 조작의 중심
Repository는 데이터베이스와 직접 상호작용하는 역할을 한다. Entity에 대한 Create, Read, Update, Delete (CRUD) 연산을 수행한다.
데이터베이스 쿼리를 생성하고, 실행해서 데이터를 읽거나 수정한다. Repository는 Entity의 상세한 데이터 접근을 다루고, 데이터베이스와의 중간 계층 역할을 한다.
🤝 Service: 비즈니스 로직의 중심
Service는 비즈니스 로직을 처리하고 제어하는 역할을 한다. Repository를 활용하여 데이터베이스와 상호작용하며, 여러 Repository를 조합하여 복잡한 비즈니스 로직을 수행한다.
데이터베이스 연산 결과를 가공하거나 여러 데이터베이스 연산을 조합하여 비즈니스 요구 사항을 충족한다. Repository 및 Entity와 서비스 간의 중재자 역할을 한다.
💬 Controller: 클라이언트와의 대화
Controller는 HTTP 요청과 응답을 처리하고 클라이언트와 상호작용하는 역할을 한다. 사용자 요청을 받아서 Service를 호출하고 Service의 응답을 클라이언트에게 반환한다.
라우팅 및 미들웨어를 설정하고, 요청의 유효성 검사 및 인증을 수행한다. HTTP 응답 및 상태 코드를 설정하여 클라이언트에게 응답을 제공한다.
🤔 왜 구분이 필요할까?
Repository, Service, Controller 이 구분은 코드를 더 명확하게 구조화하고, 역할을 분리하여 유지보수성을 향상시킨다. 비즈니스 로직과 데이터베이스 조작이 분리돼서 코드 재사용성과 테스트 용이성을 높여준다. 또한, 다양한 데이터베이스 및 클라이언트 요청과의 상호작용을 관리하는데 도움이 된다.
코드의 재사용성은 이해가 가지만 테스트 용이성을 왜 높여주는지에 대해서 많이 궁금해 할 수도 있다고 생각하기 때문에 그 이유에 대해서 설명을 하고자 한다. (사실 내가 잘 몰라서,,)
Repository는 데이터베이스 조작과 관련 로직을 분리하면 테스트할 때 실제 데이터베이스 대신 테스트용 데이터베이스 또는 Mock을 사용할 수 있다.
이를 통해서 단위 테스트를 작성할 때 데이터베이스 의존성 제거를 하고, 테스트를 할 수 있다. 이렇게 하면 테스트 코드의 빠른 실행과 안전성을 보장할 수 있다.
Service는 비즈니스 로직을 독립적으로 테스트하기가 더 쉽다. 비즈니스 로직에 집중해서 테스트 케이스 작성하고, Service 레벨에서 비즈니스 규칙을 테스트할 수 있다.
테스트 용이성은 코드의 신뢰성을 높이고, 미리 버그를 발견할 수 있다.
