728x90

spring boot로 게시판을 만들다가 구현 위주로 작업을 하고 있는데 왜, 어떻게 돌아 가는지 궁금해서 구조를 알아보고자 한다.

1. src/main/java 디렉토리 (제일 중요)

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

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

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를 만들어서 로직을 조작하는 것입니다.

DTO란?

https://kkh1902.tistory.com/155?category=977211

2. SpringboardApplcation 클래스

DemoApplication 파일을 열어보면, main 메소드가 선언되어 있는 것을 확인할 수 있습니다.

main 메소드는 웹 어플리케이션을 실행하는 역할을 해줍니다.

@SpringBootApplication 어노테이션은 main 클래스에 있는 어노테이션이고,

해당 어노테이션은 다음의 세 가지 어노테이션으로 구성되어 있습니다.

3. src/main/resources 디렉토리

templates :

기존의 스프링은 HTML 내에 자바 코드를 삽입하는 JSP의 방식을 사용하였습니다.

디렉토리의 위치도 웹 디렉토리에 해당하는 src/main/webapp 안에 존재하였습니다.

하지만, 이러한 방식은 war 파일로 패키지화 되었을 경우에만 정적 리소스를 정상적으로 사용할 수 있다고 합니다.

그러한 이유로 스프링 부트는 src/main/resources 디렉토리 내에서 화면과 관련된 파일을 관리하는 것으로 생각할 수 있습니다.

스프링 부트는 타임리프(Thymeleaf) 템플릿 엔진의 사용을 권장하는데, 타임리프는 JSP와 마찬가지로 HTML 내에서 데이터를

처리하는 데 사용됩니다.

즉, 타임리프(Thymeleaf)의 파일들(HTML파일이 동적일 때, 서버에서 데이터를 다룰 때)

templates 폴더에서 사용합니다.

static :

정적 컨텐츠는 서버에서 뭐 하는거 없이 파일을 웹브라우저에 그대로 내려주는 것이고,

해당 폴더에는 css, fonts, images, plugin, scripts 등의 정적 리소스 파일이 위치합니다.

스프링 부트는 기본 설정으로 정적 컨텐츠를 /static에서 찾아서 제공을 합니다.

application.properties :

해당 파일은 웹 어플리케이션을 실행하면서 자동으로 로딩되는 파일입니다.

예를 들어 톰캣(Tomcat)과 같은 WAS(포트 번호, 콘텍스트 패스 등)의 설정이나, 데이터베이스 관련 정보 등 각각으로

분리되어 있는 XML 또는 자바 기반의 설정을 해당 파일에 Key - Value 형식으로 지정하여 처리할 수 있습니다.

4. src/test/java 디렉토리

해당 디렉토리에는 DemoApplicationTests 클래스가 생성되어 있는데,

해당 클래스를 이용해서 각각의 개발 단계에 알맞은 테스트를 진행할 수 있습니다.

기존의 스프링과 다르게 복잡한 설정 없이 테스트가 가능합니다.

build.gradle

해당 프로젝트의 Type을 그래들(Gradle)로 선택

메이븐(Maven)은 pom.xml

메이븐(Maven)과 그래들(Gradle)의 개념 및 비교

MVC 패턴