Controller, Service, Repository 가 무엇일까?

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

MVC 패턴이란?

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

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

MVC 패턴을 사용하는 이유

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

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

자 이제 MVC패턴을 알아 보았고 이제 스프링에서의 Controller가 뭔지 알아보도록 하겠습니다!

Controller 란?

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

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

Controller를 왜 사용할까요??

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

Spring에서의 Controller사용법

스프링에서의 컨트롤러를 지정해주기 위한 어노테이션은 @Controller와 @RestController가 있습니다.

저는 RestController를 사용해봤지만 Controller는 아직 사용해본적이 없기에 둘의 차이를 한번 찾아보았습니다.

1. @Controller(Spring MVC Controller)

전통적인 Spring MVC의 컨트롤러인 @Controller는 주로 View를 반환하기 위해 사용합니다.
하지만 @ResponseBody 어노테이션과 같이 사용하면 RestController와 똑같은 기능을 수행할 수 있습니다.

예시코드

@Controller
public class Controllerprac {
    @GetMapping("/home") //home으로 Get요청이들어오면
    public String homepage(){
        return "home.html"; //home.html생성
    }
}

2.@RestController(Spring Restful Controller)Permalink

RestController는 Controller에서 @ResponseBody 어노테이션이 붙은 효과를 지니게 됩니다.

즉 주용도는 JSON/XML형태로 객체 데이터 반환을 목적으로 합니다.

예시코드

@RestController // JSON으로 데이터를 주고받음을 선언합니다.
public class ProductRestController {

    private final ProductService productService;
    private final ProductRepository productRepository;

    // 등록된 전체 상품 목록 조회
    @GetMapping("/api/products")
    public List<Product> getProducts() {
        return productRepository.findAll();
    }
}

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가 알맞은 정보를 가공하는 과정을 '비즈니스 로직을 수행한다.' 라고 합니다.
Service가 비즈니스 로직을 수행하고 데이터베이스에 접근하는 DAO를 이용해서 결과값을 받아 옵니다.

DAO란?

단순하게 페이지를 불러오고 DB정보를 한번에 불러오는 간단한 프로젝트의 경우 Service와 DAO는 차이가 거의 없을 수 있다고 합니다.

DAO 는 쉽게 말해서 Mysql 서버에 접근하여 SQL문을 실행할 수 있는 객체입니다.

그러면 이렇게 생각 할수 있습니다 JPA는 그러면 뭐야?

DAO 와 JPA

Spring Data JPA는 매우 적은 코드로 DAO를 구현할 수 있도록 해줍니다. 즉 인터페이스를 만드는 것 만으로도 Entity (@Entity)클래스에 대한 insert, Update, Delete, Select 를 실행할 수 있게 해줍니다. 뿐만 아니라 인터페이스에 메소드를 선언하는 것 만으로 라이트한 쿼리를 수행하는 코드를 만드는것과 동등한 작업을 수행합니다.

그러면 JPA를 사용하면 DAO는 직접 구현을 안해도되겠네요! 라는 생각을 할 수 있습니다.
하지만 JPA가 만들 수 있는 코드는 매우 가볍고 쉬운 쿼리를 대체하는 것이라서 복잡도가 높아지면 사용하기가 매우 어렵다고 합니다!...

이때 JPA만으로만 사용한다면 수행능력이 SQL을 직접 사용해서 개발하는 것보다 못한 상황이 벌어 질 수도 있습니다.
그래서 JPA를 깊게 공부를 해서 JPA로 복잡도가 높은 쿼리를 짜거나 아니면 복잡도가 높은 곳은 DAO로 같이 사용한다고 합니다.

Reposity 란?

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

저희는 JPA로 Reposity를 만들어 볼것입니다!

자 이렇게 ProductRepository라는 인터페이스에 JpaRepository를 상속해주면됩니다! 저기서의 Product는 Entity 클래스 명이고 Long은 그 Entity클래스의 PK의 자료형을 넣어주면 됩니다.

자그러면 이 ProductRepository에 JPA가 기본적으로 제공되는 메서드를 사용할수 있게 됩니다.

결론