Spring Controller / Service / Repository란?

[요약내용]

> controller

브라우저(클라이언트)와 상호작용하는 부분

실제 사용자의 요청을 받고, 정보의 가공이 필요할 경우 비지니스 영역(service)에 데이터를 전달한다.

 

> service

controller에서 전달받은 데이터를 토대로 원하는 로직을 처리한다. 

그 후 repository를 이용하여 원하는 데이터를 DB에 저장, 혹은 조회와 같은 기능으로 가져온다.

 

> repository

DB에 접근하기 위한 메소드들을 가지고 있으며, 이를 이용해 데이터가 DB에 접근할 수 있게한다.

 

 

찾아본 결과 Controller가 무엇인지 알기 전에 MVC 패턴에 대하여 먼저 아는 것이 중요합니다!

MVC 패턴이란?

MVC패턴은 Model-View-Controller의 약자로서 개발을 할 때 3가지 형태로 역학을 나누어 개발하는 방법론입니다.

• Model
  어플리케이션이 무엇을 할 것인지 정의하는 부분입니다. 즉 DB와 연동하여 사용자가 입력한 데이터나 사용자에게 출력할 데이터를 다룹니다.
• View
  사용자에게 시각적으로 보여주는 부분입니다. (UI)
• Controller
  Model이 데이터를 어떻게 처리할지 알려주는 역할을 합니다. 사용자에 의해 클라이언트가 보낸 데이터가 있으면 모델을 호출하기전에 적절히 가공을 하고 모델을 호출합니다. 그런다음 모델이 업무 수행을 완료하면 그결과를 가지고 View에게 전달하는 역할을 합니다.

MVC 패턴을 사용하는 이유

사용자가 보는 페이지, 데이터처리, 그리고 이 2가지를 중간에서 제어하는 컨트롤, 이 3가지로 구성되는 하나의 애플리케이션을 만들면 각각 맡은바에만 집중을 할 수 있게 됩니다.

즉 서로 분리되어 각자의 역할에 집중할 수 있게끔하여 개발을 하고 그렇게 애플리케이션을 만든다면, 유지보수성, 애플리케이션의 확장성, 그리고 유연성이 증가하고, 중복코딩이라는 문제점 또한 사라지는 효과를 가질수 있기 때문에 MVC 패턴을 사용합니다.

 

 

Controller 란?

앞에서의 MVC패턴 설명과 똑같이 Controller은 MVC에서 C에 해당 하며 주로 사용자의 요청을 처리 한 후 지정된 뷰에 모델 객체를 넘겨주는 역할을 합니다.

즉 사용자의 요청이 진입하는 지점이며 요청에 따라 어떤 처리를 할지 결정을 Service에 넘겨줍니다. 그후 Service에서 실질적으로 처리한 내용을 View에게 넘겨줍니다.

 

Controller를 왜 사용할까요??

저는 아직 대규모 서비스를 경험하지 못하였지만 만약 대규모 서비스중 A서비스, B서비스, C서비스 등등 있다고 하겠습니다. 그러면 이 많은 종류의 서비스를 한 클래스를 만들어서 꽉꽉 몰아 처리할 게 아니라 Controller라는 중간 제어자를 만들어서 A서비스에 대한것은 A-Controller가 맡고 B서비스는 B-Controller 이런식으로 역할에 따라 설계를 하고 코딩을하면 개발비용이나 유지보수비용이 대폭 줄어들기 때문에 Controller를 사용한다고 합니다!

 

 

Service 란?

자 Service를 이해하기 위해 큰 틀을 보겠습니다.

1. Client가 Request를 보낸다.(Ajax, Axios, fetch등..)
2. Request URL에 알맞은 Controller가 수신 받는다. (@Controller , @RestController)
3. Controller 는 넘어온 요청을 처리하기 위해 Service 를 호출한다.
4. Service는 알맞은 정보를 가공하여 Controller에게 데이터를 넘긴다.
5. Controller 는 Service 의 결과물을 Client 에게 전달해준다.

Service가 알맞은 정보를 가공하는 과정을 '비즈니스 로직을 수행한다.' 라고 합니다.

 

 

Reposity 란?

Entity에 의해 생성된 DB에 접근하는 메서드 들을 사용하기 위한 인터페이스입니다. @Entity라는 어노테이션으로 데이터베이스 구조를 만들었다면 여기에 CRUD를 해야겠죠?? 이것을 어떻게 할 것인지 정의해주는 계층이라고 생각하면 됩니다!

 

한 블로그에서 명확하게 정리해준 것 같아 참고용으로 먼저 제시합니다.

컨트롤러 : @Controller (프레젠테이션 레이어, 웹 요청과 응답을 처리함)
로직 처리 : @Service (서비스 레이어, 내부에서 자바 로직을 처리함)
외부I/O 처리 : @Repository (퍼시스턴스 레이어, DB나 파일같은 외부 I/O 작업을 처리함)

https://codevang.tistory.com/258

@Repository, @Service 어노테이션

---

Controller

그림을 먼저 참고해봅시다.

위 사진은 웹 서버가 클라이언트와 소통할 때 어떤 로직을 거쳐서 정보가 전달이 되는지에 대한 그림입니다.

가장 위쪽에 보면 front-end에서 들어오는 클라이언트 측의 요청이 가장 먼저 서버 측과 맞닿는 부분이 바로 Controller입니다.
서버에서 기능별 URL이라는 API를 개설해 놓았고, 클라이언트는 필요한 정보를 얻기 위해 적절한 API에 요청하는 것이죠.
즉 Controller는 이런 창구 역할을 하는 API들을 모아놓은 클래스입니다.
당연히 정보를 프론트 쪽으로 내려줄 때도 이 컨트롤러의 API를 통해서 보내줍니다.

Repository

Repository는 직역해도 '저장소'로 데이터베이스와 깊은 연관이 있음을 알 수 있습니다.
맞습니다. 데이터단에 직접 매칭되는 Entity라는 것이 있는데, 이 Entity를 통해 데이터 테이블이 생성이 되면, 받아온 정보를 데이터베이스(ex. MySQL, mariaDB)에 저장하고 조회하는 기능을 수행합니다.

위 사진은 일반적인 데이터베이스(MySQL)과 이를 조작하는 SQL문과 매칭되는 개념으로, 스프링부트에서 Domain(Entity)가 table에 , Repository가 SQL에 매칭됩니다. 즉 Repository에서 주어진 jpa 인터페이스 메소드를 활용하여 기본적인 CRUD를 할 수 있습니다.
그러나 클라이언트가 원하는 정보를 주기 위해 단순 데이터조회로는 처리하지 못하는 개념들이 있을 것 입니다. 이때 더욱 고도화된 정보 가공을 처리하는 곳이 밑에서 설명할 Service입니다.

Service

Service는 매우 애매하면서도 확실한 녀석인 것 같습니다.
Service는 위에서 언급했듯이 Repository에서 얻어온 정보를 바탕으로 자바 문법을 이용하여 가공 후 다시 Controller에게 정보를 보내는 곳입니다.
어떻게 보면 Controller는 클라이언트에, Repository는 데이터에 맞닿아서 정보를 주고받는 부분으로 여길 수 있으나 실질적으로 중요한 작동이 많이 일어나는 부분이라고 할 수 있습니다.
제가 주목했던 것은 '그럼 repository에서 정보를 가져오면 바로 가공해서 컨트롤러한테 주면 되는데 굳이 service가 필요한가'에 대한 것입니다.
그러나 같은 궁금증을 가진 사람이 많아보였고, 정보를 조금만 찾아봐도 여러 정보가 나왔습니다.
(지금부터 얘기하는 부분은 service와 직접적인 연관은 없다고 느낄 수도 있습니다)

결론부터 말하자면 클라이언트 즉 controller 쪽에서 바로 데이터베이스에 접근하여 정보를 얻고 가공해서 가져가는 것은 위험합니다. 정보를 직접 CRUD하고 가공하는 과정에서 테이블에 저장된 원본의 정보가 손상될 우려가 크기 때문입니다. 따라서 정보 변동의 위험이 큰 로직은 Service에서 진행하는 것입니다. 추가로 이때도 원본의 데이터를 사용하는 것이 아니라 데이터베이스에서 추출한 정보의 복사본인 DTO를 만들어서 로직을 조작하는 것입니다.