72일 - ★스프링이란 (=프론트 컨트롤러=Spring MVC 라이브러리= Dispatcher Servlet), devtool 라이브러리 추가하기, @GetMapping, @PostMapping

*복습* 

Spring이란? '???을 도와주는' 라이브러리

1) DI

2) Transaction

3) MVC

4) JDBC 연동

....계속 포함시키다보니 라이브러리 많아지고 설정도 많아짐 

-> Spring Boot

 

 

 

어떻게 도움을 주는지를 이제 하나하나 살펴보는 것

 

예전) 요청이 오면, 그 요청에 맞는 서블릿 코드들이 있었고 @어노테이션을 붙였었음

현재) @RequestMapping("/")로 울타리?를 만들고 @어노테이션을 붙임 

 

요청 들어오면 요청을 가로챈 다음에(@WebServlet이) 작업을 하는 것

@Controller 안에 것들은 사실상 각각의 Controller인 것 

1) 실질적으로 업무 담당 컨트롤러

2) 앞단의 컨트롤러 (프론트 컨트롤러, Spring MVC 라이브러리)

- 애 덕분에 우리는 1에만 집중할 수 있게 되는 것. Thank you. 

- 입출력, 매핑... 등등 다 2가 처리함

- 실제로 엄청 편하다. (parameter 받는 것들을 2가 다 처리해줘서)

- 예전에는 1한테 일을 시키기 위해 XML을 이용했던...  그래서 1도 XML을 읽어야 했고(Controller는 어디에 있고~ 이런 정보는 이거고 저거고..) 

 

Q. XML에서 바뀐 이유

- 협업을 한다고 할 경우, 다른 사람이 XML을 수정했다면? 

  이런 상황을 방지하기 위해 XML을 쪼개놓는데 이것도 불편

- 왔다갔다 하는 것도 불편 ('아 XML에서 url 바꿔줘야한다.')

- 배포할 때 설정도 재설정해서... 

 

XML 사용하지 않고, @어노테이션 사용하는 장점

- 설정, 업데이트를 따로 해줄 필요 x 

- 협업 때도 그냥 각자 맡은 class 만들면 됨

 

---

Spring MVC 라이브러리 (프론트 컨트롤러)를 알아보자. 

- 애 덕분에 입출력, 매핑이 쉬워진 :)

-> 우리는 설정만 잘 해주면 됨 :) 

 

 

(헷갈려할까봐 추가 설명. 아래는 @Controller 달린거 봐서 알겠지만 프론트 컨트롤러가 아님)

- 각 서비스 역할하는거 만들어주는거임 for 프론트 컨트롤러의 편리성을 알기 위해

 

 

URL이 길다. 줄여보자.

 

반복된다. 길다. 

Controller에도 url 매핑이 가능!

이렇게 간단하게 해줄 수 있다 :) 

 

//

 

다른 noice도 고쳐보고

 

// 

 

이제 실행을 해볼건데

예전 같으면 저장하면(ctrl s) 되었는데... '사이트 연결할 수 없다'고 나옴

- 서버가 없는 것처럼 

 

재시작해보자

 

Q. 수정이 일어날 때마다 이렇게 재시작해줘야 하나?

->

left to right 선택하고 finish

그럼 저절로 POM에 라이브러리가 추가가 되고

라이브러리 추가 되었는지 POM 들어가서 확인하기

 

import 된다.

 

//

 

원래는 이렇게 추가하면 서버를 재시작해야했지

 

 

그런데 devtool 설치하고는

이제 그냥 '저장'만 누르잖아?

->

그럼 바로 뜸!! 

 

우선 devtool을 추가하면 서버는 재시작을 해야함

 

//

 

스프링 5점대는 최신 버전 

4점대가 제일 많이 사용 중

- 버전 따라가는 기업은 없다.

 

그래서 지금 배우는건 4점대 방식

 

admin의 함수를 보면 get방식과 post 방식을 두 개 다 줘야하는 함수들이 존재.

먼저 reg를 해보자.

- get 방식, post 방식을 조건 처리하는 것보다는 따로 주는게 더 좋겠지~ 

 

옛날 방식

4점대 버전 방식

 

 

옛날에는 라이브러리를 직접 매핑했었음

-> 우리는 지금 Boot 잖아? ㅎㅎㅎ 직접 설정할 필요 없음.

 

// 이제 사용자에게 입출력하도록 해야 (가장 중요한 프론트 컨트롤러의 역할)

 

[입력]

1) get 요청으로 쿼리스트링

2) post에서 form 기반으로

+ 3) header 정보

+ 4) cookie 

 

등록은 @post 여기서 입력받겠지

 

우선 static 폴더 안에 test.html 하나를 등록해보자

-

url에 가서 test.html 

여기에 2,4 입력하면 (아무 숫자나 입력하면) 

이 화면이 뜸 

이렇게 해줬기에! 

 

//

 

프론트컨트롤러는 그냥 서블릿

- Controller를 호출함

- Controller를 다 읽음

 

프론트 컨트롤러가 가지고 있는건 다 사용 가능

- 대신 선언을 해야함 (프론트컨트롤러가 request 있던데 나도 그거 쓸거야! 등) 

 

request로 p=1이 오면?

 

과거 방식

과거 방식

// 

 

(아래 Spring 정리하고 다시 되돌아옴ㅎㅎ)

 

this.

- 객체는 클래스들을 얻어올 수 있음

Notice.class.

- 그리고 클래스는 메소드를 얻어올 수 있지

Notice.class.getMethod

- 그리고 invoke하면 전달할 수 있다는 것

invoke 다음에는 parameter도 가능

 

우리는 '라이브러리를 사용하는 사람'이라는 것을 잊지 말자 ~ 

지금은 just 이렇게 사용한다~ 정도를 알아두기

 

//

이제 직접 저렇게 안한다는 것

그냥 String p를 받는다고만 쓰면 ~! 

request 요청하고 일치한다 싶으면, 중간에 꺼내주는 코드가 들어감 (갓스프링 ☆)

이거를 Spring이 해준다는 것! (Dispatcher Servlet, Spring MVC, Front Controller)

 

---

2) 두번째 방법

1번 방법

2번 방법

url / test.html 해서 

-> 숫자 입력한 다음에 출력하면... 

대박이댱.

 

근데 예외 사항이 있음

- 저렇게 단순하게 오면 좋은데 예외들이 있다.

 

넘겨받는 값이 지금은 숫자인데, 우리가 사용하는 방식은 '문자'

-> 문자를 바꿔서 써야함. 

 

귀찮

 

-> 숫자 x로 받게 됨

기본값은 0

 

Q. 빈공백으로 줘도 

-> 기본값으로 넣어줌

 

Q. 기본값에 있는 "0"은 문자인데 뒤에 Integer 적어줬기에 숫자라고 함.

 

//

 

defaultValue 말고 다른 속성도 있음

//

값을 받다보면...

 

우리가 쿼리스트링으로 보낼 경우 이름을 줄이곤 한다.

ex) field 의 name ="f"라고 한다던지

 

그럼 받는 것도 내가 f라고 써야함

그럼 내가 fullname으로 쓰려면 따로 선언해줘야 하지.

 

-> Spring 또 등장 "내가 해결해드리오~~" 

 

name=f로 올건데 그걸 field로 해달라

 

// 전에 하던 코드량보다 훨씬 줄어듬! 

 

 

 

 

 

 

 

 

 

 

 

---

* 정리 * 

 

스프링이 프론트 컨트롤러임 = Spring MVC 라이브러리라고도 하는거고 = Dispatcher Servlet이라고도 하고 

서블릿

url 배분을 해줌, 입출력에 관여

 

모든 요청을 다 받아서 적절한 녀석을 호출해줘야

- 여기에는 뭐 있고, 뭐 있고를 알려주는걸 예전에는 xml에 해줬는데 이제는 @어노테이션으로 해주고 있다. 

 

@RequestMapping -> get, post 둘 다 받을 수 있음

 

@GetMapping 

@PostMapping

 

//

예전 방식

- Controller 여기서 다 서블릿 

- 톰캣의 부속물로 있지 여기서는 (너무 종속되어 있음. 톰캣이 없어지면...? was 중 하나가 톰캣인데 다른 was 사용하려면..?)

-> 이 종속성을 낮추려는 것 ! Controller 업무 로직에 독립성을 주자! 

- 톰캣과의 접점 / 결합력을 낮추려는 생각을 하게 된 것

 

▽

 

-> 내가 만든 Controller가 서블릿이 아니여야 함. 이걸 원했었음

- runtime 환경에 구속되지 않은 형태로 만듦. POJO 클래스. 

- 자바 객체

 

Q. 접점을 어떻게 낮추나? 

- 서블릿을 하나만 두고! (애만 영향 받도록 하고) 나머지들은 톰캣에 영향 받지 않도록 하자.

그래서 URL 매핑을 '모든 URL'로 받는 것

 

이 '디스패처 서블릿'은 매핑 정보를 알아야함

 

그래서 서블릿은 하나만 (톰캣에 영향받는) 

오른쪽 Controller들은 서블릿 아닌거로 내가 자유로이 만들고

 

이건 작성하는게 아닌거라고 함

 

누가 만들어도 비슷함 

-> 그러면 전 세계 개발자들이 Dispatcher를 각각 만들 필요가 있나? 

- 만드는 기술이 어려운 것도 아니고... 

  100명 프로젝트라고 하면 100명이 다 만들 필요가 없는 것...

-> 만들어놓은걸! 쓰기 시작

 

옛날엔 '스트러치'라는걸 사용했엇음 (struts) 

-> Spring 등장! 두둥

 

DI, transaction만 Spring 

MVC는 원래 stuts가 담당했는데 여기를 Spring이 넘봐서는 이것도 하게 된 것! 

---

프론트 컨트롤러 한 번 만들어보자 (for 이해)

 

-> 환경에 종속되지 않도록 고쳐보는 것

- 지금은 너무! 서블릿거임

- 이걸 '드러내는' 작업을 미리 해놓는 것

 

새로 하나 만들어서 

여기서만 서블릿 향기를 풍기겠다! 

 

나머지 Cotroller는 어떻게 하냐면

-> 다 매핑을 해줘야 함

---

// 기존거는 너무 매핑 많아서 새로 하나 만들어보자. (dynamic project)

 

이건 약속된것

 

//

 

indexController, helloController 에는 '내 마음'!대로 만드는 것

- 이름도 내 마음대로

 

오로지는 서블릿은 하나

- 모든지 다 이걸 거쳐서 POJO들로 가는 것

 

uri 전달되면

-> if로 판단. 이거로 전달되는게 있으면~ 

-> 거기에 맞게 class를 만들어서 호출

내가 만든 컨트롤러를 호출해주는 역할

 

POJO (오른쪽) 보면 

- 톰캣에 종속되지 X

- 업무로직에 관련된 것만 적으면 되는 것

 

//

L

reuqest가 있으니 뭘 받아서 전달해줄 수도 있는 것

이거를! Spring이 만들어준다는 것 (예전에는 struts)

 

R

애가 view를 활용할 수도 있어야 

- 필요한 view를 리턴값으로 줄 수도 있음

근데 new를 이렇게 계속 해주지는 않음

-> xml 하나 만들어서 (dispatcher 가 사용하는 xml) 

- "/notice/list"를 담당하는건, com.newlecture ... 이렇게 설정을 함

-> 이렇게 해줌. 

그리고 for문..... @_@ 

 

-> 만들어놓은걸 쓴다!는 것. 

 

// 우리는 R만 만들어서 쓰면 됨.

- 아이러니한컨 톰캣에서 종속되었지만 Spring에 종속됨 ㅎㅎㅎ