우선, 이 글을 읽기 전 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을 알아야하는지 대충이라도 감은 잡혔으리라 생각한다.