<MVC패턴>Controller & Servicec & Repository란 무엇일까?(TIL.220525)

박건영(Parkgunyoung)·2022년 5월 25일

Controller MVC MVC패턴 repository service

til

목록 보기

8/17

Controller & Servicec & Repository 란 무엇일까?

<MVC 패턴?>

MVC패턴은 Model – View – Controller 의 약자로써 개발을 할 때 3가지 형태로 역할을 나누어 개발하는 방법론이라고 한다.

Model

어플리케이션이 무엇을 할 것인지 정의하는 부분이다. 즉, DB와 연동하여 사용자가 입력한 데이터나 사용자에게 출력할 데이터를 다룬다.

View

사용자에게 시각적으로 보여주는 부분이다. (UI)

Controller(사용자가 보는 페이지, 데이터처리 사이에서 중간제어자 역할을 한다)

Model이 데이터를 어떻게 처리할지 알려주는 역할을 한다. 사용자에 의해 클라이언트가 보낸 데이터가 있으면 모델을 호출하기전에 적절히 가공을 하고 모델을 호출한다. 그 다음 모델이 업무 수행을 완료하면 그 결과를 가지고 View에게 전달하는 역할을 한다.

MVC패턴을 사용하는 이유?

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

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

Controller란?

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

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

Controller를 왜 사용할까?

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

<Spring에서의 Controller>

스프링에는 컨트롤러를 지정해주기 위해 어노테이션을 @Controller 와 @RestController를 사용한다.

<그럼 이 둘의 차이는 무엇일까?>

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

@RestController는 @Controller와 @ResponseBody 이 둘의 기능을 묶은 것이라고 생각하면 된다.

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

JSON & XML 에 대한 간단한 지식

<JSON이란>

JavaScript Object Notation (JSON)은 Javascript 객체 문법으로 구조화된 데이터를 표현하기 위한 문자 기반의 표준 포맷입니다. 웹 어플리케이션에서 데이터를 전송할 때 일반적으로 사용합니다(서버에서 클라이언트로 데이터를 전송하여 표현하려거나 반대의 경우).

<XML이란>

XML은 EXtensible Markup Language의 약자이며, 1998년에 W3C 표준 권고안에 포함되었습니다.

XML은 HTML과 매우 비슷한 문자 기반의 마크업 언어(text-based markup language)입니다.
이 언어는 사람과 기계가 동시에 읽기 편한 구조로 되어 있습니다.

그러나 XML은 HTML처럼 데이터를 보여주는 목적이 아닌, 데이터를 저장하고 전달할 목적으로만 만들어졌습니다.
또한, XML 태그는 HTML 태그처럼 미리 정의되어 있지 않고, 사용자가 직접 정의할 수 있습니다.

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를 이용해서 결과 값을 받아온다.

(여기서잠깐! : DTO는 계층 간 데이터 교환을 위해 사용하는 객체로, DTO 는 로직을 가지지 않은 순수한 데이터 객체(getter&setter 만 가진 클래스)이다.
유저가 자신의 브라우저에서 데이터를 입력하여 form에 있는 데이터를 DTO에 넣어서 전송한다.
해당 DTO를 받은 서버가 DAO를 이용하여 데이터 베이스로 데이터를 집어넣는다.)

DAO?

단순하게 페이지를 불러오고 DB정보를 한번에 불러오는 간단한 프로젝트에서는 Service와 DAO의 차이는 거의 없다고 한다.
다시말해 DAO는 MYsql 서버에 접근하여 SQL 문을 실행할 수 있는 객체이다.

<DAO 와 JPA의 차이>

DAO도 MYsql 서버에 접근하여 SQL문을 실행할 수 있다하는데 그럼 JPA와 같은 역할을 하는게 아닌가 라는 의문점이 생길 수 있다.

하지만 JPA는 매우 적은 코드로 DAO를 구현할 수 있게 해준다(킹 가성비). 인터페이스를 만드는 것 만으로 Entity(@Entity)클래스에 대한 Insert, Update, Delete, Select를 실행할 수 있게 해준다 한다.

더 나아가 인터페이스에 메소드를 선언하는 것 만으로도 라이트한 쿼리를 수행하는 코드를 만드는 것과 동등한 작업을 수행한다.

이렇게 보면 당연히 DAO 구현 안하고 JPA만 쓰면 되겠다 라는 생각이 들지만 JPA가 만들 수 있는 코드는 매우 라이트하고 쉬운 쿼리를 대체하는 정도라 복잡도가 올라가면 사용하기가 힘들어진다고 한다.

이럴경우 JPA만 사용한다면 효율이 SQL을 직접 사용해서 개발하는 것보다 못한 상황이 온다. 그렇기에 JPA로 복잡도가 높은 쿼리를 짜거나 아니면 복잡도가 높은 것들은 DAO를 같이 사용한다고 한다.

<Repository란?>

Entity에 의해 생성된 DB에 접근하는 메서드 들을 사용하기 위한 인터페이스이다.

@Entity 라는 어노테이션으로 데이터베이스 구조를 만들었다면 이제 여기에 CRUD를 해야한다.

그렇다면 이것을 어떻게 할 것인지 정의해주는 계층이라고 생각하면된다.

public interface BlogRepository extends JpaRepository<Blog, Long> {
    //JPA가 개발자 대신 적절한 SQL을 생성하여 DB에 전달하고, 객체를 자동으로 Mapping해준다
    //Blog는 Entity 클래스명 Long은 Entity 클래스의 pk의 자료형이다.
}