WAS, MVC 패턴에 대하여

• 웹 어플리케이션 서버 : WAS
  • 네트워크 어딘가에 ip가 필요하다. (server Computer의 위치)
  • 'service'를 지칭하는8080. 서비스 자리에 위치하는 것이 WAS이고,
  • 현재 나는 톰캣을 쓰고있다. 이제는 JVM에서 돌아가는 것이 아님
  • was 다음 context까지 가야 내가 원하는 구현부가 들어가있음. 
  • ~localhose:8080/context... === container root/context root
• life cycle이 있는 survlet
  • init, service, doget/dopost, deestroy
• 객체에 대한 상태 관리도 WAS가 하는 일이다. - WAS가 container이기 때문.
• 웹의 요소를 호출하려면 필요한 것은?
  • 어디에 있는 url을 어떻게 호출하지? get/post
  • post로 동작하는 경우는 명시적으로 post라고 쓰는 경우 뿐이다. 나머지는 다 get!
• /의 사용
  • html에서 사용하는 / : container root를 의미한다.
• 처리!
  • 요청을 처리하는 HttpServletRequest
    • 가장 대표적으로 parameter를 받아올 수 있다.
    • String type의 name. (parameter의 key값).
  • 서비스를 동작시키는 HttpServlet
  • 응답을 처리하는 HttpServletResponse
    • response와 관련 있음!
    • getWriter 등으로 받아오자.
    • 한글 깨진다. encoding 꼭!
• MVC design pattern과 Model2
  • 어제도 했는데 모든 application을 분석하면 Model, View, Controller로 구성된다.
  • Model : business logic 처리. DAO..
  • View : Display
  • Controller : client의 요청을 제일 처음으로 받아들이는 곳.
• MVC 동작
  • client->controller (사용자의 요청).
  • controller ->model (요청)
  • model-> controller (결과 전달)
  • controller->view (화면 요청)
  • view->client (사용자에게 응답)
• 페이지 전환 방식
• servlet과 jsp는 동일 JVM 내에 있다. 
  • forward
    • client의 요청을 그대로 전달. jsp에서 request를 그대로 사용할 수 있다.
    • client의 요청 횟수 1회
    • location bar 변경되지 않는다. 기존 url 유지
  • sendRedirect
    • client의 요청 -> servlet이 응답 -> jsp를 소개해준다 -> client가 jsp에게 요청 (직접은 아님) ->jsp가 client에게 응답
    • client의 요청 횟수 2회. 요청 간에는 접점 관계가 존재하지 않음. "전혀" 다르다~~~
    • location bar : 이동하는 page로 변경