슬로

https://imslo.tistory.com/35

https://imslo.tistory.com/33

https://imslo.tistory.com/34

https://imslo.tistory.com/31

https://imslo.tistory.com/32

<MVC> 

Model - View - Controller의 디자인 패턴. 비지니스 로직과 화면을 구분하는 데 중점을 두고있다.

Model : 데이터와 비지니스 로직을 관리

View : 레이아웃과 화면을 처리

Controller : 사용자의 요청을 필요에 따라 View, Model에게 전달(라우팅)

동적인 화면의 경우, Controller가 View(동적 HTML)와 Model(적용할 정보들)을 템플릿 엔진에 전달하면, 엔진은 이를 그려서 동적 웹 페이지를 클라이언트(브라우저)에게 내려준다.

Spring에서는 template engine으로 Thymeleaf를 사용하는 것을 권장하고 있다.

==================================================================================

<Controller> : Response

@RequestMapping("URL")

/response로 들어온 요청들은 이 클래스에서 처리하게 됨. => 이 아래 메서드들은 respone의 하위 URL들이 된다.

@Controller ==> 해당 클래스 / 메소드가 MVC 패턴의 Controller에 해당한다는 것을 알려줌

-기본적으로 @Controller는 view를 반환하게 되어있다. 따라서, return "hello"는 String 타입의 hello를 반환하는 것이 아니라, view로서 hello.html을 반환하게 된다.

동적인 html에서 ${count} 등의 변수를 명시해놓으면, controller 안에서 Model.addAttribute("count", 123) 등으로 주입가능

하지만 모든 요청이 view를 요청하는 것은 아니다. 데이터를 JSON형태로 받아야 할 경우에는 @Controller에 더해

@ResponseBody  annotation을 붙여준다. Controller이긴 하지만, view가 아닌 데이터를 반환하는 메서드임을 알려준다.

@RestController 는 @Controller와 @ResponseBody를 합쳐놓은 것.

==> 데이터를 받아오는 클래스일 경우 @RestController를 붙이면 될듯

==> 전통적 MVC에서는 모델이 view를 반환하여 @Controller를 주로 사용하였다.

==> 프론드와 백엔드를 분리하여 백엔드에서 데이터만 보내주는 최근 방식(REST한 아키텍쳐)에서는 @RestController를 많이 사용

============================================================================================

@Controller annotation이 모든걸 처리해주기 때문에 개발자 입장에서는 controller가 시작이자 끝처럼 보이겠지만, 사실 Spring 내부적으로 많은 일들이 일어나고 있다.

-Servlet에서 Client의 요청을 받음

-Servlet에서 API를 처리해줄 Controller를 Handler에서 찾아 전달 (Handler에는 API path와 Controller함수가 짝지어져있)

-Controller -> Servlet(ViewResolver) -> Client

해당 내용은 추후에 더 깊게 공부해보기

============================================================================================

<Controller> : Request 

클라이언트에서 요청 시, controller가 그 데이터를 어떻게 받는지

@PathVariable

@RequestParam

@ModelAttribute

@RequestBody

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

@PathVariable

Path(URL)를 통해서 들어온 값을 받는다.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

@RequestParam (GET)

URL의 /form/param 뒤에 ?name=슬로2&age=12332 부분을 쿼리스트링이라고 한다. 

@RequestParam은 Get방식에서 쿼리방식으로 보낸 값을 받아올 수 있다.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

@RequestParam (POST)

Payload의 소스보기를 보면, GET방식과 마찬가지로 쿼리스트링에 데이터가 들어있다. 따라서 똑같이 @RequestParam으로 데이터를 받아올 수 있다.

하지만, POST방식으로 데이터를 받아올 때는 URL에 쿼리 내용이 드러나지 않는다.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

@ModelAttribute

데이터를 객체로 받는다. 이 때, 객체는 setter가 있어야하며, 변수는 객체의 필드명으로 접근 가능

RequestParam이나, PathVariable은 필드값이 여러개일때 받아오기 어렵기 때문에 이렇게 받을 수 있다.

@ModelAttribute는 생략 가능. 그냥 객체로 받겠다고 쓰면 됨

이 때, 받으려는 객체의 필드이름은 데이터를 보내는 곳의 variable 이름과 일치해야하며, setter가 필요하다

데이터는 마찬가지로 쿼리형식으로 전달되며, POST방식이므로 URL에 드러나지 않는다.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

@RequestBody

form태그의 Body를 받아오는 방식이다. Body는 JSON 형태로 전달된다.

받아오는 객체가 있어야하며, PathVariable이나 RequestParam처럼 변수명을 명시해서 받아올 수 없다.

https://imslo.tistory.com/26

https://imslo.tistory.com/27

https://imslo.tistory.com/28

https://imslo.tistory.com/25

https://imslo.tistory.com/24

https://imslo.tistory.com/23