🚩 1.3. Web MVC 방식

🏁 개요

• JSP를 사용한 개발 방식은 ❶유지보수 ❷URL 변경이 유연하지 못하다는 단점이 있다.

• 2000년대 중반 이후 개발은 거의 MVC 형식으로 서블릿과 JSP를 함께 이용한다.

🏁 MVC 구조와 서블릿/JSP

• 서블릿 코드는 자바 코드와 문법(상속, 인터페이스) 처리가 가능하지만 HTTP로 전달된 메시지를 구성하는 HTML을 처리할 때 효용성이 낮다.

• JSP의 경우 HTML 코드를 바로 사용할 수 있으므로 HTTP 메시지 작성에는 적합하지만,
  그 안에 자바 코드를 재사용하는 문제나 자바 코드와 HTML이 혼재하는 문제가 존재한다.

그렇다면 서블릿과 JSP의 역할을 나눠보면 어떨까?

➡️ 브라우저 요청은 해당 주소를 처리하는 서블릿에 전달되고,
서블릿 내부에서는 JSP로 다시 전달하여 EL을 이용한 결과 데이터를 생성한다.
(브라우저 → 서블릿 → JSP → 브라우저)사진 출처 : JSP / Servlet(서블릿)의 MVC 패턴

• 서블릿 : 응답에 필요한 데이터 완성 / 다른 객체들 연동 협업 처리 / 상속이나 인터페이스 활용 / 코드의 재사용
  
  
• JSP : EL을 이용해서 데이터 출력 / HTML 코드 활용 / 브라우저로 전송할 최종 결과 완성

• 웹 MVC는 'Model - View - Controller'의 역할을 분리해서 처리하는 구조로 데이터는 컨트롤러(Controller)에서 결과는 뷰(View)에서 처리한다.
  
  모델(Model)은 컨트롤러에게 가공할 데이터를 전달한다.

  • 서블릿이 컨트롤러, JSP가 뷰 역할을 담당하게 하는 것이 편리하다.

MVC 구조로 다시 설계하는 계산기

• MVC 구조에서 명심해야 할 원칙

  • 브라우저 호출은 반드시 컨트롤러 역할을 하는 서블릿을 호출한다.
  • JSP는 브라우저에서 직접 호출하지 않도록 하고 Controller(서블릿)를 통해서만 JSP에 접근하도록 구성한다.

GET 입력화면 설계

1. 브라우저는 /input과 같이 특정한 주소를 호출
2. /input에 맞는 서블릿을 InputController로 작성하고, GET 방식일때만 동작하도록 작성

   • HTTPServlet에서 상속받은 doGet() 메서드를 오버라이딩 하면 될 것이다.

3. Inputcontroller의 화면 처리는 input.jsp를 이용하도록 지정
4. input.jsp에는 HTML 코드를 이용해 브라우저에서 볼 수 있는 결과를 생성

POST 처리의 설계

1. input.jsp의 <form> 태그의 action을 ‘/calcResult’와 같이 변경하고 이에 해당하는
   CalcResuLtServLet 서블릿을 컨트롤러로 작성.
2. CalcResultServlet은 <form>으로 전달되는 numl, num2 데이터를 읽어내서 결과 데이터를 만듦.

   • 데이터를 가공하는 역할은 컨트롤러 (여기서는 서블릿)이 수행한다!

3. 만들어진 결과를 calcResult.jsp와 같이 JSP로 전달해야 하고 JSP에서는 결과 데이터를 출력합니다

   • 데이터를 출력하는 역할은 View를 맡고 있는 JSP에서 수행한다!

컨트롤러에서 뷰(View) 호출

• 서블릿을 생성할 때는 JSP와 달리 src/main/webapp 폴더에 생성하는 것이 아니라, src/main/java 폴더에 패키지를 만들어서 생성한다.

• @WebServlet(name = "inputController" , urlPatterns = "/calc/input")

  • @WebServlet 어노테이션⭐은 웹 서블릿으로 하여금 url 매핑을 하게 한다.
  • JAVA에서 @WebServlet은 어노테이션의 주요 속성은 name, urlPatterns, value가 있다.
    - name은 서블릿의 이름을 설정한다. 기본값은 빈 문자열("")이다.
    - urlPatterns는 서블릿의 URL 목록을 설정한다.
    속성값으로 String 배열을 지정하며, 기본 값은 빈 배열({})이다.
    - value는 urlPattern과 같은 용도이다. 어노테이션에서 단일 속성 value는 생략 가능.
    
    
  • 참고:
    - @WebServlet 사용하기
    - 서블릿 구현 및 실행 (web.xml, @WebServlet 설정)
    - 서블릿(Servlet) url 매핑기법 2가지(web.xml, 어노테이션)

• RequestDispatcher dispatcher = req.getRequestDispatcher("/WEB-INF/calc/input.jsp");

  • RequestDispatcher⭐는 ❶클라이언트로부터 최초에 들어온 요청을 JSP/Servlet 내에서 원하는 자원으로 요청을 보내는 역할을 수행하거나, 특정 자원에 처리를 요청하고 ❷처리 결과를 얻어오는 기능을 수행하는 클래스이다.
    
    
  • req.getRequestDispatcher(URL주소)는 URL 주소에 대한 RequestDispatcher 객체를 ServletRequest를 통해서 얻는 방법
    
    
  • [서블릿/JSP] REQUESTDISPATCHER란. REQUESTDISPATCHER로 FORWARD() 하기

• dispatcher.forward(req, resp);

  • forward() 메서드는 대상 자원으로 제어를 넘기는 역할을 한다.
  • 브라우저에서 /a.jsp로 요청했을 때 /a.jsp에서 forward()를 실행하여 /b.jsp로 제어를 넘길 수 있다. 제어를 넘겨받은 /b.jsp는 처리 결과를 최종적으로 브라우저에게 출력한다. 브라우저 입장에서는 /a.jsp를 요청했지만 받은 결과는 /b.jsp의 결과이다. 이때 HTTP 리다이렉트 방식과는 달리 하나의 HTTP 요청(Request) 범위 안에서 동작이 이루어진다.

RequestDispatcher를 이용한 요청(Request) 배포

• RequestDispatcher는 서블릿에 전달된 요청(Request)을 다른 쪽으로 전달 혹은 배포하는 역할을 한다. InputController 서블릿은 /WEB-INF/calc/input.jsp라는 목적어를 가는 중간 경유지가 된다. (49p)

  • InputController를 거치기 때문에 해당 서블릿의 작업을 모두 실행한 이후 input.jsp로 리다이렉트 된다.

• 기존 사용하던 input.jsp와 calcResult.jsp는 WEB-INF 경로 밑으로 이동시킨다.

• WEB-INF 폴더의 경우 브라우저에서 직접적으로 접근이 불가한 경로다.
  - WEB-INF 폴더에 있을 경우 localhost:8090/WEB-INF/test.jsp로 접근이 불가하다. 이로인해 유저의 직접 접근이 어렵워 보안성이 높다.
  - 직접적으로 view를 볼 수 없다. 또한 직접적으로 볼 수 없기 때문에 <a> 앵커 태그로 이동이 불가하며 Controller를 통해서만 이동을 해야 한다.
  
  
• [스프링 개념] web과 WEB-INF 폴더에 관해서 및 WEB-INF에서의 앵커 태그<a>에 관해서

POST 방식을 통한 처리 요청

• 사용자가 입력한 숫자의 처리는 POST 방식으로 전송할 것이므로 이를 처리하는 컨트롤러 CalcController 생성

CalcController의 생성

• 서블릿은 doPost()라는 메소드를 오버라이드해서 POST 방식으로 들어오는 요청(Request)를 처리할 수 있다.
  CalcController라는 서블릿을 추가해서 POST 요청을 받아보자.

• @WebServlet(name="calcController" , urlPatterns = "/calc/makeResult") :
  웹 서블릿의 urlPattern 값이 /calc/makeResult로 되어 있으므로 form 태그의 action 속성을 재지정해주어야 한다.
  (WEB-INF/calc/input.jsp 의 form action 재지정)

• doPost() : 브라우저에서 POST 방식으로 호출하는 경우에만 호출이 가능함.

• String num1 = req.getParameter("num1"); ,
  String num2 = req.getParameter("num2"); :
  HttpServletRequest.getParameter(파라미터 이름)으로 전달된 변수를 받고 있다. 숫자가 아닌 문자열 String 타입으로 받는 것을 주의해야 한다.

MVC 패턴에 의한 요청 흐름 정리

1. http://localhost:8080/calc/input로 브라우저에서 GET 요청

2. 해당 url이 매핑된 웹 서블릿 InputController가 요청 객체의 RequestDispatcher 객체를 얻어 /WEB-INF/calc/input.jsp로 forward 시킴.

3. /WEB-INF/calc/input.jsp의 form 태그에는 SEND라는 버튼을 누르면 POST 방식의 요청을 /calc/makeResult라는 url로 진행하도록 form 태그 설정이 되어 있음.

4. /calc/makeResult url이 매핑되어 있는 CalcController 서블릿이 form 태그를 통해 전달된 num1과 num2의 변수를 저장함.

• ⭐ MVC 패턴에 의해 비즈니스 로직은 Controller(서블릿)가 처리하고 View(JSP)가 화면단을 구성한다.
  
  ➡️ URL 변경과 자바 코드를 사용하는 유지보수에 자유로움

sendRedirect()

• 💡POST 방식의 처리는 가능하면 빨리 다른 페이지를 보도록 브라우저 화면을 이동시키는 것이 좋다.
  
  (😊 POST 요청은 멱등성을 가지고 있지 않으므로 POST를 계속 요청하면 서버나 DB에 계속하여 중복된 요청이 생기는 문제가 발생할 수 있기 때문이겠구나!)
  
  PRG 패턴 (Post-Redirect-Get) - 삽질중인 개발자
  ⚡새로고침으로 인한 동일한 요청이 연속적으로 보내지는 이슈
  ⚡POST 요청은 URL을 복사하더라도 다른 사람과 공유할 수 없다는 점

• 이 때 HttpServletResponse의 sendRedirect()를 사용한다.
  

  • https://dololak.tistory.com/502 : RequestDispatcher가 있는 이유. HttpServletResponse#sendRedirect() 와의 차이점
    
    
  • HttpServletResponse를 사용하면 sendRedirect() 메서드를 이용하여 지정한 경로로 제어를 이동시킬 수 있습니다. 그러나 sendRedirect()는 HTTP 리다이렉션을 이용하기 때문에 하나의 요청 범위 안에서 처리를 하는것이 아니라 브라우저에게 Response 후 브라우저측에서 지정받은 요청 경로로 다시 재요청을 하는 방식이기에 두 번의 HTTP 트랜잭션이 발생하며, 서버측에서는 최초에 받은 요청중에 처리한 내용을 리다이렉트 된 요청안에서 공유할 수 없는 문제가 있습니다.
    
    
  • 물론 sendRedirect() 에서도 쿠키나 세션등을 이용해 특정 상태를 유지하여 공유할 수는 있겠으나, 상황에 따라 제한적일 수 있으며, 코드 레벨 에서의 알고리즘 등을 곧바로 이어가는데에도 한계가 있기 때문에 좋은 방법이라고 할 수는 없을것 입니다.
    
    그대신 HttpServletResponse를 통해 리다이렉트 하는 방식은 현재 어플리케이션 이외에 다른 자원의 경로를 요청할 수 있는 반면 RequestDispatcher는 현재 처리중인 서블릿이 속해 있는 웹 어플리케이션 범위 내에서만 요청을 제어할 수 있습니다.

• CalcController의 doPost() 수정
  

PRG 패턴(Post-Redirect-GET)

• 웹 MVC 구조에서 가장 흔하게 사용되는 패턴은 POST 방식과 Redirect를 결합해서 사용하는 PRG 패턴⭐이다.
  

1. P : POST 방식으로 데이터의 처리를 요청 => Controller A
2. Controller A => 데이터를 처리하고 브라우저에게는 다른 주소로 Redirect하도록 응답
3. 브라우저는 이동해야 하는 주소를 받는다.
4. 브라우저는 해당 주소(서버)를 GET 방식으로 호출 => Controller B
5. Controller B => GET 방식의 데이터를 처리하고 응답 메시지 전송
6. 브라우저로 응답

• PRG 패턴은 게시판이 대표적이다.

  • 사용자 => 새 게시글 작성 POST 방식으로 전송
  • 서버에서 게시글 처리 후 브라우저 주소를 목록 화면 경로로 이동하도록 응답(Redirect)
  • 브라우저는 목록 화면을 보여주고 사용자는 자신 추가 게시글이 추가된 결과 확인

PRG 패턴의 장점

• PRG : POST 방식 처리 후에 바로 다른 주소로 브라우저가 이동한다.
  ❶ 반복적으로 POST 호출이 되는 상황을 막을 수 있다.
  ❷ 사용자 입장에서도 처리가 끝난 후 다시 처음 단계로 돌아간다는 느낌을 받는다.

PRG 패턴을 이용한 와이어 프레임 작성하기 (55~59)

• 웹의 경우 여러 페이지를 만들 때 이동이 많기 때문에 우선 설계를 통해서 어떤 흐름으로 동작하게 되는지 미리 구성해보는 문서가 와이어 프레임(wire frame)⭐이다.
  (출처 : https://www.geeksforgeeks.org/how-to-create-a-wireframe-in-software-design/)
  
  와이어 프레임을 사용하면 화면과 화면 사이에 어떤 일들이 처리되어야 하는지 쉽게 구분하고 분류할 수 있다.

Todo 웹 애플리케이션 와이어 프레임 그리기

• 와이어프레임 그리기 원칙

  • 화면에는 해당 페이지를 볼 수 있는 경로(URL)를 명시한다.
  • GET 방식으로 동작하고 눈에 보이는 것을 가장 먼저 구성한다.
  • POST 방식으로 처리되는 컨트롤러는 다른 그림으로 표현한다.
  • Redirect되어 보여지는 경우는 다른 선으로 표현한다.

• 와이어 프레임으로부터 구현 목록을 정리할 수도 있다. (59 그림 참조)