이 뭐길래 Spring 할 때 알아야 할까? - 2
우선, 이 글을 읽기 전 Servlet 이 뭐길래 Spring 할 때 알아야 할까? - 1 을 읽어보고 오는것을 추천한다.
Dispatcher Servlet
우선, Servlet은 요청 하나하나에 Servlet을 정의해준다.
으잉? 이게 무슨소리야?
라고 할텐데 자세히 알아보도록 하자
Servlet의 요청 처리 방법
일반적으로 Servlet은 web.xml에 요청 하나하나를 다 등록해주어야 한다.
<web-app>
<servlet>
<servlet-name>web</servlet-name> //servlet 이름 명시
<servlet-class>servlet.WebServlet</servlet-class> //패키지.클래스 이름을 등록 해줌
</servlet>
<servlet-mapping>
<servlet-name>web</servlet-name> //servlet의 name을 매핑
<url-pattern>/web</url-pattern> / 가 반드시 필요!! (주소 뒤에 값이라서)
</servlet-mapping>
</web-app>
예를들어 /web 이라는 경로로 요청이 들어오게 되었을때를 작성했는데 다른 경로도 마찬가지로 이런식으로 하나하나 다 정의를 해서 매핑해주어야 한다.
결국 1:1 매칭이 되게끔 해주는것이 Servlet 이라는것이다.
이는, 가게의 입장에서 예를 들어보면 수십명의 직원이 있지만, 이 직원들은 각각 하는일이 완벽히 분리가 된 것이다.
햄버거집으로 예시를 들자면
- 빅맥을 담당하는 직원
- 슈비버거를 담당하는 직원
- 치즈버거를 담당하는 직원 등등
이런식으로 나뉘게 된다. 얼마나 비효율적이고 생산성이 떨어지는가?
Spring의 요청 처리 방법
web.xml을 작성한다는거 자체가 정말 생산성이 좋지 않다.
이를 위해 나온것이 Spring인데 이 Spring도 Servlet을 기반으로 하고 있는데, 이는 Servlet 처럼 하나하나 다 매핑해줄 필요가 없다.
Spring의 설정
Spring도 Servlet을 기반으로 한다고 위에 말을 했다.
그렇기에 Spring도 매핑을 해주지만, Dispacher가 이를 해결해준다.
또 다시 햄버거집으로 예를 들면
한 사람이 주문을 받고, 이 직원이 알바생에게 넌 빅맥만들어! 넌 슈비버거만들어! 넌 치즈버거만들어! 와 같은 명령을 내린다는것이다.
Dispatch Servlet
좋다, 이제 왜 Spring을 할 때 Servlet을 배워야하는지 어느정도 감이 잡힌것같다.
그런데 Dispatch Servlet이 이것만 담당을 하는가?
그건 또 아니다 위 이미지는 정말 생략된것이 많고, 그냥 보기 편하게만 그려놓은것이다.
이를 더 자세히 파보자면 아래와 같은 이미지가 된다.
개발자들은 저 그림의 원으로 된 부분만 신경을 쓰면 되는데, 동작 순서와 함께 저것들이 하나하나 뭔지 알아보도록 하겠다.
요청 → Dispatcher Servlet → Handler Mapping → Dispatcher Servlet → Handler Adapter → Controller → Handler Adapter → Model And View → Dispatcher Servlet →View Resolver → Dispatcher Servlet → View → Dispatcher Servlet → 응답
여기서 작동되는 구체적인 로직은 다음에 더 깊이 공부를 할 때 알아보도록 해야겠다.
왜냐하면, 더 자세히 찾아보다보니 대부분 원으로 그려진 Controller 와 View 부분만 신경을 쓰면 되지만, 실제로 운영을 하고 딥하게 구현을 들어가게되면 이 때 사각형으로 그려진 부분도 건드리게 된다고 한다.
일단 여기까지 알아보앗을 때 왜 Spring을 할 때 Servelt을 알아야하는지 대충이라도 감은 잡혔으리라 생각한다.
Author And Source
이 문제에 관하여(이 뭐길래 Spring 할 때 알아야 할까? - 2), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@vpdls1511/Servlet-이-뭐길래-Spring-할-때-알아야-할까-2저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)