Controller, Repository, Service 분리 이유
- 스프링에서 한곳이아닌 여러 파일로 분리후 Controller, Repository, Service등으로 역할을 분리한 이유는 소프트웨어의 구조적인 모듈화와 관심사의 분리를 하기 위한 것입니다. 각각의 역할을 달리가져 서로 다른 책임과 역할을 수행하며, 이를 통해 유지보수성,모듈화, 테스트 용이성,확장성을 개선할 수 있습니다.이 구조는 소프트웨어 공학에서 자주 사용하는 MVC 패턴과도 깊은 연관이 있습니다.
1. MVC 패턴
MVC 패턴이란?
-> MVC는 Model, View, Controller의 약자 하나의 애플리케이션,프로젝트를 구성할 때 그 구성요소를 세가지 역할로 구분하는 패턴
모델(Model)
-> 소프트웨어나 애플리케이션에서 정보 및 데이터 부분을 의미 Controller에게 받은 데이터를 조작(가공)하는 역할을 수행 즉, 데이터와 관련된 부분을 담당하며 값과 기능을 가지는 객체
Model이 가지는 규칙
-
사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 함
-
View나 Controller에 대해서 어떤 정보도 알지 말아야 함
-
변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야만 한다.
뷰(View)
-> View는 입력 값이나 체크 박스 등과 같은 사용자 인터페이스 요소를 나타냄 Controller에게 받은 Model의 데이터를 사용자에게 시각적으로 보여주기 위한 역할을 수행 즉, 사용자에게 보여지는 화면이라고 볼 수 있다.
View가 가지는 규칙
-
Model이 가지고 있는 정보를 따로 저장해서는 안된다.
-
Model이나 Controller를 알고 있을 필요가 없다.
-
변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다.
컨트롤러(Controller)
-> Controller는 Model과 View 사이에서 데이터 흐름을 제어 함 사용자가 접근한 URL에 따라 요청을 파악하고 URL에 적절한 Method를 호출하여 Service에서 비즈니스 로직을 처리한다. 이후 결과를 Model에 저장하여 View에게 전달하는 역할을 수행한다. Controller는 Model과 View의 역할을 분리하는 중요한 요소이다.
Controller가 가지는 규칙
-
Model이나 View에 대해서 알고 있어야 한다.
-
Model이나 View의 변경을 모니터링 해야 한다.
2.Controller, Service, Repository의 역할
Java에서 흔히 사용하는 계층형 아키텍처에서 Controller, Service, Repository는 각각 아래와 같은 역할을 담당합니다:
Controller(프레젠테이션 계층)
- 클라이언트의 요청을 받아 처리
- 사용자의 입력을 받아 Service 계층에 전달
- Service 계층에서 반환된 결과를 클라이언트에게 응답
- 요청 매핑, 파라미터 바인딩, 예외 처리 등의 역할
Service(비즈니스 로직 계층)
- 애플리케이션의 핵심 비즈니스 로직을 구현
- Controller에서 전달받은 데이터를 가공하고 처리
- 필요한 경우 Repository 계층을 호출하여 데이터를 조회, 생성, 수정, 삭제
- 트랜잭션 관리, 보안, 로깅 등의 부가 기능을 수행
Repository(데이터 접근 계층)
- 데이터베이스와의 직접적인 통신을 담당
- CRUD(Create, Read, Update, Delete) 작업을 수행
- 엔티티 객체를 데이터베이스 테이블에 매핑
- Service 계층에서 호출되어 데이터를 조회, 저장, 수정, 삭제
계층으로 나누는 이유
프로그래밍을 하다보면 지속적인 유지보수와 업데이트로 인해 처음에는 간단한 로직이 굉장히 복잡해지고, 어느순간 스파게티 코드가 될 수 있는 위험이 있다. 코드는 남이 이해하기 쉽고, 안전하게 작성하는 것이 매우 중요하다. 이를 방지하기 위해 개발자들은 하나의 서비스를 만들때 계층을 나누고 이 계층이 크게 Controller - Service - Repository로 나뉜다.
3. 유지보수성과 확장성의 연관
모듈화와 관심사의 분리 (Separation of Concerns):
3.1 모듈화
각 계층(Controller, Service, Repository)은 명확한 책임을 가지고 있으며, 이로 인해 코드의 모듈화가 이루어집니다. 모듈화된 코드는 쉽게 이해할 수 있으며, 특정 기능의 수정이 필요할 때 해당 모듈만 수정하면 되므로 유지보수가 용이합니다.
3.2 관심사의 분리
비즈니스 로직, 데이터 접근, 사용자 인터페이스를 분리함으로써 각 레이어의 변경이 다른 레이어에 미치는 영향을 최소화할 수 있습니다. 예를 들어, 비즈니스 로직을 변경할 때 데이터베이스 접근 코드나 UI 코드를 건드릴 필요가 없습니다.
3.3 확장성과 유연성
각 계층이 독립적으로 존재하기 때문에 특정 기능이나 컴포넌트를 쉽게 확장할 수 있습니다. 예를 들어, 새로운 비즈니스 로직을 추가하거나, 데이터 소스를 교체하는 작업이 용이합니다.
Service 계층을 사용함으로써 여러 다른 Controller가 같은 비즈니스 로직을 재사용할 수 있습니다. 이로 인해 코드의 중복을 줄이고, 새로운 기능을 추가할 때 기존 코드를 재사용할 수 있어 확장성이 높아집니다.
3.4 테스트 용이성
각 계층을 독립적으로 테스트할 수 있습니다. 예를 들어, Repository를 테스트할 때 데이터베이스와의 상호작용만 검증하면 되며, 비즈니스 로직이나 UI와 관련된 코드는 제외됩니다.
단위 테스트(Unit Test)가 용이해지며, 테스트 커버리지를 높일 수 있습니다. 이는 버그를 조기에 발견하고, 안정성을 높이는 데 기여합니다.
3.5 유지보수성과 배포
코드의 변경이 최소화되므로, 배포 시에도 위험이 줄어듭니다. 예를 들어, 비즈니스 로직에 변화가 생겼다면 Service 계층만 수정하고 배포할 수 있습니다.
여러 개발자가 동시에 작업하기에 적합한 구조입니다. 각자 다른 계층에서 작업하더라도 충돌을 최소화할 수 있습니다.
결론
Controller, Service, Repository를 나누는 것은 MVC 패턴의 철학을 따르면서 애플리케이션의 유지보수성과 확장성을 극대화하기 위함입니다. 이 구조를 통해 코드의 복잡성을 줄이고, 모듈화를 강화하며, 테스트와 배포를 용이하게 할 수 있습니다. 또한, 개발 과정에서 발생할 수 있는 의존성 문제를 최소화하고, 각 계층이 자신의 책임에만 집중할 수 있게 만들어 개발 생산성을 높이고, 애플리케이션의 신뢰성을 강화할 수 있습니다.
