[Spring 공부] 김영한님의 입문 강의 - 3

Spring Boot를 처음 공부하는 사람이 공부한 내용을 정리해서 작성한 포스트입니다. 오개념 및 오류가 있을 수 있으니, 발견하신다면 가감없이 댓글을 통해서 알려주세요! 확인하는 대로 정확한 정보를 확인해서 고치도록 하겠습니다.

개요

이번 Spring Boot 스터디는 배달의 민족의 김영한님께서 인프런에 올려주시는 자바 스프링 완전 정복 시리즈를 기반으로 진행한다. 그 시리즈의 가장 첫 강의인 스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술을 들어보고 간단히 정리해보고자 한다.

해당 강의는 내가 느끼기에 크게 다음의 컨텐츠를 가지고 있었다.

• Spring 기초 기능 써보기
• Spring Bean과 의존 관계
• 회원 관리 예제 구현하기
  • Controller - Service - Repository 패턴 적용
  • Spring MVC 적용
• 위의 예제에 다양한 DB 접근 기술 적용
  • JDBC
  • JDBC Template
  • JPA
  • Spring Data JPA
• 위의 예제에 간단한 AOP 적용

이 포스트에서는 회원 관리 예제 구현하기에 대해서 정리해보도록 하겠다.

회원 관리 예제 구현하기

강의에서 기본 기능을 다뤄본 후 곧장 회원 관리 예제 구현에 돌입한다. 이 챕터의 핵심은 스프링에서 사용하는 패턴인 Controller - Service - Repository 패턴에 대해서 가볍게 살펴보고, 이를 앞서 배운 MVC에 적용하여 데이터에 관련된 로직과 뷰를 보여주기 위한 로직을 연결해 회원 관리 예제를 구현해내는 것에 있다. 나는 코드에 대한 부분보다 개념 자체에 조금 더 집중해서 글을 써내려가보도록 하겠다.

Controller - Service - Repository 패턴 적용

일반적으로 Spring Boot 어플리케이션의 경우 다음의 계층 구조를 가지고 있다.

구조에 대한 설명

여기서, 화살표는 “출발하는 곳이 도착하는 곳을 사용한다” 정도로 생각하면 편할 것 같다. 즉, “Controller가 Service를 사용한다” 와 같은 느낌이다.

각각의 요소들의 역할은 다음과 같다.

• Domain : 유저에게 제공 혹은 관리하고자 하는 특정 정보에 대한 객체이다. 예를 들어 회원, 게시글, 댓글 등으로 주로 데이터베이스에 저장하여 관리한다.
• Controller : 우리가 지금껏 작성한 Controller이다. 웹 MVC의 Controller이기도 하다.
• Service : 우리가 제공하는 제품에 있어 핵심적인 비즈니스 로직을 구현하는 부분이다.
• Repository : 저장소라는 의미를 가지고 있고, DB에 직접 접근하는 부분이다. 여기서 Domain 객체를 DB에 저장하고 관리한다.

그러면 우리가 만든 어플리케이션에 어떤 요청이 들어오면 다음과 같은 절차를 거치게 될 것이다.

1. Tomcat에 의해 특정 Controller로 요청이 들어온다.
2. 해당 Controller가 특정 Service에 비즈니스 로직 수행을 요청한다.
3. 해당 Service는 비즈니스 로직을 수행하면서, DB에 접근할 필요가 있을 때마다 Repository에 요청하여 데이터를 관리한다.

구현에 대한 특징

보통 Repository를 구현할 때, Service는 직접적으로는 Repository의 인터페이스에 의존 관계를 가지도록 설계한다고 한다. 이렇게 하면 DB의 종류가 바뀌거나, DB에 접근하는 방법이 바뀌더라도 Service의 구현을 바꾸지 않고 그대로 사용할 수 있기 때문에 객체지향의 장점을 누릴 수 있다.

또한, Service와 Repository를 구현하다 보면 (특히 간단한 예제일수록 더) Service와 Repository의 구현이 거의 비슷하거나 하는 일이 거의 같다고 느낄 수 있는데 , 이 부분을 유의해야 한다. 간단한 예제를 구현할 경우 굳이 위의 패턴을 적용하지 않아도 되는 경우가 많기 때문에 더 그렇게 느낄 가능성이 높은데 Repository는 DB 접근을 대행하는 역할의 느낌이고 Service는 가져온 데이터로 요리킹조리킹을 해서 필요한 형태로 변환해 Controller에게 다시 건네주는 역할의 느낌이다.

Spring MVC 적용

그러면 Controller - Service - Repository를 구현하고 나면 MVC에서 어디가 M, 어디가 V, 그리고 어디가 C가 되는 것일까? 아무래도 View는 ThymeLeaf Template Engine을 사용하는 부분이 될 것 같고, Controller는 우리가 구현한 Controller, 그리고 나머지 Service와 Repository가 Model이라고 생각할 수 있을 것 같다.

여기서 나는 이 Spring MVC가 왜 MVC라는 이름을 가지는 것인지 의문을 가지게 되었다. 왜냐하면 MVC 패턴에서는 사용자의 입력이 Controller를 통해 들어오고, 이것으로 인해 Model이 업데이트 되며, 이 Model을 기반으로 View가 업데이트되게 되어있기 때문이다. 그런데 지금 배운 Spring MVC의 경우 Model(Service, Repository)를 통해 가공한 데이터를 Controller에게 전달하고 이것이 View Resolver에게 전달되어 View가 업데이트 되는 구조로 되어있다. 즉, Model이 View를 업데이트 하는 것이 아니라 Controller가 View를 업데이트 한다. 이는 MVP 패턴에 더 가깝지 않나라는 생각이 들었고, Spring MVC라는 이름에 의문을 가지게 되었다. 이에 대해서 조금 더 알아보아야 할 것 같다.

이런 부분을 차치하고, 지금까지 한 흐름을 그대로 이용하면 특정 주소와 HTTP method를 매핑하여 Controller로 요청을 받고, 그에 알맞는 비즈니스 로직을 Service를 통해 실행하고(그리고 이 Service는 DB에 접근이 필요할 때마다 Repository에 요청하고) 이것을 다시 Controller에서 받아서 최종 결과를 return 하면 @ResponseBody 라는 어노테이션이 붙어있지 않는 이상 View Resolver를 통해서 특정 Template을 찾아서 그것을 html로 렌더링하여 유저에게 보내주게 될 것이다.

다음은

다음 포스트에서는 이 예제에 다양한 DB 접근 기술을 적용하는 내용에 대해서 간략히 정리해보도록 하겠다.

끝.