훈수/저작권 관련 지적 환영합니다 - 댓글 또는 audgnssweet@naver.com
Controller
MVC 디자인 패턴에 대해서 들어보셨을 것입니다.
아래 그림을 보겠습니다.
Controller는 사용자의 요청이 들어오는 곳입니다.
해당 요청에 대한 실질적인 처리도 Controller가 담당하지는 않습니다.
처리 자체는 Model에게 맡기고 결과만 받아서 View에게 전달, 사용자에게 보여주게 됩니다.
Controller의 사용 이유
Controller의 사용 이유 == MVC 아키텍처의 등장 이유
개발 초기에는 MVC의 구분 없이 한 소스에 전부를 구현했다고 합니다.
초기 개발 자체는 편할지 몰라도, 코드 전체가 엉켜있다 보니 유지 보수가 힘들고, 요구사항의 변화에 유연하게 대처하기 힘들었다고 합니다.
(개발은 항상 유지 보수가 쉬운 쪽으로 발전하는 것 같습니다.)
똑똑한 개발자들이 핵심 기능을 기준으로 코드 덩어리들을 분류하자 떨어져 나온 것이 Model, View, Controller입니다.
정리> 역할 분담을 통한 코드의 분리 - 유지보수의 유리함
예시
- 사용자가 "/list" url로 HTTP Get method 요청을 보냅니다.
- DispatcherServlet이 알맞은 Controller에게 매칭 해줍니다.
- Controller는 내부적으로 getList 함수를 호출합니다.
- getList에서 Model을 이용한 데이터 처리를 합니다.
- Controller는 ModelAndView 객체를 만들어 DispatcherServlet에게 전달합니다.
- DispatcherServlet이 해당 객체를 이용해 사용자에게 결과를 보여줍니다.
(함수에서 반환하는 "list"는 문자열이 아니라 DispatcherSerlvet에 설정해놓은 ViewResolver를 통해. jsp파일을 리턴합니다.)
RestController
@RestController = @Controller + @ResponseBody
Controller VS RestController
기존의 Controller는 위에서도 알 수 있듯, View(+Model)을 반환합니다.
RestController는 View가 아닌, Data를 반환합니다. (가장 큰 차이)
특히나 JSON형식의 데이터를 반환하는 것이 주목적입니다.
RestController 사용 이유
기존의 개발은 서버 사이드 렌더링을 했기 때문에 View 자체도 서버에서 만들어서 내려주는 방식이었습니다.
그러나 Ajax의 등장 이후로 서버에서는 데이터만 내려주고 클라이언트단에서 JSON을 컨트롤하는 방식,
클라이언트 사이드 렌더링이 많이 사용되는 추세라고 합니다.
또한 RestController을 사용하여 웹에 종속적이지 않고 여러 플랫폼에서 사용할 수 있는 API를 만들 수 있습니다. (Ex. 안드로이드)
예시
위의 Controller와 비슷한 예제입니다.
차이점은 Java 객체인 Map을 Return 한다는 것입니다.
Return 되면서 Jackson Library를 통해 JSON형식으로 바뀌고,
클라이언트에게는 JSON형태로 전달되게 됩니다.
프런트단(웹, 앱)에서는 JSON 데이터를 통해 화면을 구상할 수 있을 것입니다.
'Spring' 카테고리의 다른 글
| Argument Resolver (0) | 2021.03.02 |
|---|---|
| Interceptor (0) | 2021.03.02 |
