Controller, Service, Repository는 스프링 프레임워크의 핵심적인 구조이다.
하지만 그 전에 Controller, Service, Repository 구조의 기반이 된다고 할 수 있는 MVC 패턴에 대하여 간단히 알아보자
MVC(Mode View Controller) 패턴은 여러 디자인 패턴 중 하나로, 어플리케이션을 세 가지 주요 컴포넌트로 구분하여 설계하는 방법이다.
어플리케이션의 비즈니스 로직과 데이터를 담당한다.
Controller의 요청에 따라 DB에 접근해 CRUD 처리하여 Controller에 반환한다.
Model과 View 사이의 상호작용을 담당한다.
사용자의 요청에 따라 Model에게 요청하고, 처리된 결과를 View에게 전달한다.
UI를 표시하고 데이터의 표현을 담당한다.
뷰는 주로 모델에서 가져온 데이터를 사용자에게 보여주는 역할을 담당하며, 사용자의 입력을 받아 컨트롤러로 전달한다.
스프링 레이어드 아키텍처 패턴에 맞춰 각 레이어의 역할을 구분하여 개발하는 방법
MVC에서의 Controller와 같다.
사용자에게 요청을 받고 이를 위한 처리를 위해 Service를 호출한다.
Service로 부터 받은 Response를 View Resolver를 통해 View에서 전달한다.
즉, 사용자의 Request를 파악하여 알맞은 Service로 전달하고, View와 Service사이를 중재하는 인터페이스의 역할을 한다.
이런 특징 때문에 View와 Service는 서로의 존재를 알 필요가 없다.
이걸 간단하게 이야기하면 코드를 작성함에 있어 서로를 신경쓰지 않아도 된다는 의미이다.
예를 들면, View 컴포넌트를 개발하는데 Service 컴포넌트가 어떻게 구성되어 있는지, 어떻게 작동하는지, 무엇으로 작동하는지 전혀 알 필요가 없다. 그저 Controller(인터페이스)에 명시되어 있는대로 작성하면 될 뿐이다.
이는 앞서 꾸준히 이야기했던 객체지향의 특성(특히 DIP)과 완벽히 일치한다.
Controller의 요청에 따라 비즈니스 로직을 처리한다.
데이터가 필요할 경우 Repositoy로부터 DTO로 전달받아 처리한 후 Controller에 반환한다.
스프링에서는 Reposiroty가 모델의 역할을 한다고 볼 수 있다.
DB와 서비스를 연결하는 '저장소'로 DAO, DTO, VO 클래스로 구성된다.
DAO를 통해 JDBC로직(자바에서의 CRUD) 처리를 하며 DTO, VO 형태로 Service로 전달해 처리할 수 있도록 한다.
Step1에서 이야기 했던 객체 지향 5원칙 S.O.L.I.D의 S에 해당한다.
각각의 컴포넌트가 한 가지 주요 책임을 가지도록 분리함으로써 코드의 가독성과 유지보수성이 향상된다.
Controller는 사용자 입력을 처리하고 데이터의 흐름을 관리하며, Service는 비즈니스 로직을 처리하고, Repository는 데이터베이스와의 상호작용을 담당한다.
각 컴포넌트가 특정 작업에 집중되고, 서로 독립적으로 동작하도록 분리함으로써 모듈화할 수 있고, 각 컴포넌트의 응집도를 높이고 결합도를 낮출 수 있다.
이는 코드의 변경이 다른 컴포넌트에 미치는 영향을 최소화하고 코드의 유지보수성을 향상시킨다.
스프링의 구조와 흐름에 대해서 복기할 수 있는 시간이 되었다.
또한 조금 더 객체 지향적으로 생각을 할 수 있도록 노력해야겠다는 생각도 들었다.
글 재미있게 봤습니다.