아파치ㆍ톰캣 흐름도

클라이언트마다 요청하는게 다 다르다. 때문에 요청하는 사람마다 (요청할 때마다)
'HTTPServletRequest', 'HTTPServletResponse' 가 생긴다.

만약 'HTTPServletRequest'가 하나라면...
나는 a를 요청했는데 다른 사람이 요청한 b가 오고.. 엉망일 것

아무튼 'HTTPServletRequest', 'HTTPServletResponse' 이 2가지 정보를 가지고
Servlet 이라는 클래스가 만들어진다. (내가 new하는거 아님. 스프링이 만들어줌)

이 Servlet이 정말 중요한 메소드를 가지고 있는데 그게 바로 'service' 다.

service(HTTPServletRequest, HTTPServletResponse) {

}

'HTTPServletRequest', 'HTTPServletResponse' 가 service에 이렇게 들어온다!
그럼 우린 이 service 안에 코딩만 하면 된다!

클라이언트 한명이 요청하면 Servlet 만들어지고 service메서드 때려지고 끝! 을 반복.
이렇게 만들어지는 것이다.
(*개발자는 service가 끝나기 직전에 응답(Response)를 버퍼에 담아서 해줘야함)

그러나...... 문제가 있다. 클라이언트가가 요청을 다양한 주소로 할 수 있다. 
/hello 나 /hi 나 /bye 나 … 엄청 다양하게 요청을 할 수 있는데, 
그걸 또 파싱해서, if해서.. /hello가 들어오면 뭘 하겠다. 
데이터베이스 필요하면 rs=next.뭐 이런 과정들을 다 짜야한다.
service 안에! 그럼 엄청나게 지저분 해지겠지? 코드가 수만줄 되겠지?
(메인에다 코드 다 때려박는거랑 비슷하다고 생각하라) 

그래서 레이어가 나옴. (Dispacher - Controller - DAO 이런...)
뭐... 레이어들 없이 Servlet에 다 때려박아도 되긴 한다. 감당할 수 있다면...

[ web.xml 파일로 서블릿 매핑 ] → 역사 속으로 사라짐

web.xml 파일 (문지기가 하는 일이 적혀있는 것)은 
서블릿과 요청 URL 간의 매핑을 설정하는 역할을 한다. 

ex)
web.xml 파일에 /hello URL에 대한 요청이 들어오면 AServlet을 실행하고, 
/home URL에 대한 요청이 들어오면 BServlet을 실행하도록 설정할 수 있다

그러면 어? /hello네? 하면서 문지기쪽에서 조건문 필요 없이 
'HTTPServletRequest', 'HTTPServletResponse' 쪽으로 바로 슝 날아감

근데..문제가… 서블렛이 엄청나게 늘어나서 메모리가 엄청 늘어남
그래서 이걸 역사속에서 지웁니다. -> 안 쓴답니다^^

[ 그러니까 서블릿에 다 때려넣자고! FrontController 패턴 ]

서블릿을 나누는게 아니라, 
무슨 요청이든 하나의 서블렛으로 보내서 (서블릿을 하나로 모아서) if로 처리해야겠다!

그래서 하나의 서블릿에 모든 요청을 다!! 때려넣음!! (중앙에서 요청 처리) 
그래서 서블릿 = 프론트 컨트롤러 라고도 부른다
(*요청이 들어올 때마다 서블렛이 하나씩 만들어지면 이건 프론트 컨트롤러라고 안함)

근데..이렇게 하려면 라우터가 꼭 필요하고 코드를 if 로 다 짜놔야한다는 단점이...
/hello 요청오면 hello 메소드 때리고, /home 요청오면 내가 home 메소드를 직접 때리고! 
코드 복잡 + 유지보수도 어렵고... 그래서 리플렉션을 사용!!! 

리플렉션은 실행 시간(runtime)에 클래스의 정보를 분석하고, 
메소드를 동적으로 호출할 수 있는 기능. 

이를 통해 프론트 컨트롤러에서 요청에 해당하는 메소드를 동적으로 호출할 수 있다. 
(@어노테이션 붙여서 '/hello'로 오면 이 메소드를 실행하라 이런...)

따라서, 매 요청마다 서블릿을 직접 생성하거나 
if문으로 분기 처리하는 번거로움을 줄일 수 있다.

회사마다 service내부를 적는 방법이 다를 수가 있음.
그래서 나온게 스프링 프레임 워크임. 강제성을 부여해주는 것
이 프레임대로 코드 짜라!! 하는 것. 그럼 실수도 적고 회사마다 비스무리하겠지