Spring_MVC 패턴 기초_1편

1차 프로젝트가 끝난 후, 새롭게 배우고 있는 스프링 프레임워크! 줄여서 스프링이라고 한다고 한다. 박매일 선생님께서 우리가 1차 프로젝트에 사용했던 Model1 방식은 10년 전 현업에서 쓰던 방식이고 현재는 거의 스프링을 사용한다고 하셔서 살짝 암울했지만.. 기초부터 다지라는 큰 뜻이 있으리라 생각하며 스프링을 열심히 배우고 있다. 

 

 

1. 스프링이란?

대부분의 회사들이 현업에서 개발을 하고 있는 툴이 바로 스프링이다. 이 툴은 새로 개발한 툴이 아니라 기존의 eclipse를 한국의 니즈에 맞춰 개발해 놓은 것을 말한다. 설치를 하려면 아래 링크를 타고 가서 설치하면 된다.

https://www.egovframe.go.kr/home/ntt/nttRead.do?pagerOffset=0&searchKey=&searchValue=&menuNo=65&bbsId=4&nttId=1741

교육자료 | 표준프레임워크 포털 eGovFrame

 

그렇다면, 왜 굳이 스프링으로 개발을 해야 하느냐 하신다면, 이전 프로젝트의 문제점을 말할 수 있겠다. Java와 JDBC를 연결해서 진행한 프로젝트는 Java 소스와 SQL문이 뒤죽박죽 섞여있어서 유지보수가 굉장히 어려웠다. 뿐만 아니라 개발 속도가 느리기 때문에 생산성도 떨어진다. 단점은 보완하라고 있는 법이기 때문에 현재는 이러한 단점을 보완한 다른 방법론을 사용한다. 바로 My Batis! 

 

 

2. Spring의 흐름도 

 

출처 : https://velog.io/@lacomaco/Spring-MVC-%ED%99%9C%EC%9A%A9

 

스프링 MVC 패턴에서는 크게 2가지 Controller가 존재한다. Front Controller와 POJO! 위 그림대로 말하자면 Front Controller가 Dispatcher Servlet이고, POJO가 Controller라고 할 수 있겠다. 클라이언트의 모든 요청은 Dispatcher Servlet이 모두 받고, POJO에게 넘기면 일은 POJO가 다 한다고 보면 된다. 쉽게 기억하려면 POJO 알바생~ 알바생이 일을 다 한다~ 일 엄청 시키는 Dispatcher Servlet~

출처 : http://egloos.zum.com/springmvc/v/504151

Dispatcher Servlet이 Handler Mapping을 통해 POJO에 있는 메소드를 실행한다. 따라서 POJO에는 여러 메소드가 존재하게 되고, Handler Mapping이 그때마다 알맞는 메소드를 찾아주는 역할을 한다고 보면 된다. 네비게이션 같은 존재라고 하면 되려나? 그렇게 메소드를 실행하면 메소드는 jsp를 리턴! 이러한 구조를 위해 반드시 해줘야 할 사항은 아래와 같이 @Controller라고 어노테이션을 붙여줘야 POJO로 인식할 수 있다. 그리고 @RequestMapping도 달아줘야 요청을 알맞게 받아 처리하는 메소드가 될 수 있다. 꼭 달아주기!

 

 

하지만 위 메소드를 보면 return 값이 jsp 형식이 아니다. jsp 형식으로 보여주려면 한 단계 더 거쳐야 한다. 바로 위 그림에도 보이는 View Resolver. Dispatcher Servlet은 POJO로부터 돌려줄 페이지의 논리적 이름만 받아와서 View Resolver에게 전달한다. 그러면 View Resolver가 논리적 이름 앞 뒤로 주소를 추가 해서 jsp 파일 형식으로 바꿔준다. 경로가 바뀌거나 수정이 필요할 경우, 메소드마다 찾아다닐 필요 없이 View Resolver만 손보면 되니까 참 쉽고 간편하죠?

 

 

3. jsp를 views 폴더 아래에 만드는 이유는?

 

이전 프로젝트 때는 jsp를 만들 때  webContent 폴더에 만들고 바로 실행하곤 했었는데, Spring은 더 복잡하게 아래로 내려가서 views 폴더 안에 만든다. 처음에는 왜 그런 것인가 하고 이해가 안됐는데 박매일 선생님의 명쾌한 강의로 이해가 잘 됐다. (선생님 광고 아님)

 

그 이유는 바로 jsp를 바로 실행하면 Controller를 거치지 않고 실행하게 되기 때문에 Spring 흐름이 파삭 깨지게 된다. 따라서 그 흐름도에 따라 운영되려면 꼭 FrontController를 거치게 만들어 줘야 한다. View를 요청하지 못하게 하는 것! 

출처 : https://www.slideshare.net/parkjoongsoo1/jsp-58410192

이러한 이유로 WEB-INF 아래에 만드는데, 이렇게 되면 브라우저에서 바로 View로 가는 것을 막아줄 수 있다. WEB-INF는 보안 디렉토리라서 브라우저에 나오면 안되고, 접근 자체가 불가하다고 한다. Controller를 거칠 수 밖에..! 

 

 

너무 길어지면 지루할 수 있으므로, 이제 2편에서 API 등록하는 법과 DB 연결하는 부분까지 작성해보도록 하겠다.