[JSP] MVC Model, Front-Controller 패턴, Model2의 페이지 이동 방식

1. MVC

• JSP 방식

  

  JSP 방식

  - 처리도 jsp에서 하는 방식(jsp에서 DB 연결해서 사용)
  - 각 페이지마다 필요시 자바 코드가 작성되며, DB와 연결하는 코드도 JSP 파일 안에서 모두 작성
  - 분리되어 있지 않기 때문에 소규모 프로젝트에는 어울리는 방식이지만 가독성이 떨어지고 분업과 유지보수가 좋지 않으므로 규모가 커지면 불편해짐
• Model1 방식

  

  Model1 방식

  - b.jsp에서 DAO()의 메소드를 호출함으로써 자바 코드가 섞이게 됨
  - 하지만 선언은 분리되어 JAVA 파일에 구현되어 있으므로 JSP 내의 JAVA 코드의 양이 굉장히 줄어들게 됨
  - 페이지가 확장될수록 유지보수가 상대적으로 좋지 않음
• Model2 방식

  

  Model2 방식

  - a.jsp에서 다음 페이지로 이동하기 전에 필요한 비즈니스 로직(처리를 담당하는 곳)을 b.java 서블릿에 완벽히 분리하여 관리함
  - 요청시 알맞은 서블릿으로 찾아가기 위해 web.xml을 참고
  - 그 후 그곳에서 처리 완료된 결과를 들고 c.jsp로 이동하여 출력하는 형태
• Model2 예시
  
  

  

  - 요청을 보내면 먼저 web.xml로 찾아가서 /b라는 요청이 들어왔으니 거기에 맞는 서블릿 클래스를 찾아서 그 클래스로 가게 된다.

  

  - 서블릿 클래스로 와서 요청에서 온 파라미터를 받고 DB 처리가 필요하면 해주고 원하는 페이지로 이동하면 된다.
  - 여기서 이동할 때 sendRedirect가 있고 forward방식이 있는데, sendRedirect는 요청 정보를 초기화시키기 때문에 데이터 없이 보낼 때는 이 방법을 쓰고 데이터를 유지하면서 보내기 위해서는 forward 방식을 사용하면 된다.
  
  

  

2. Front-Controller 패턴

- 기능이 많아지면 servlet 개수가 많아지고 길어지는 문제가 발생하기 때문에 모든 요청을 한 곳에 받아오고 하나의 컨트롤러로 다시 처리로 보내주는 패턴을 이용

Front-Contrller 패턴

• 예시

  

  - 이제부터 불필요한 오류를 피하기 위해 페이지를 이동하거나 경로를 써줄 때는 절대 경로로 루트부터 차례대로 써야 하며 앞에 어떤 대상인지 붙여서 사용하는 것이 좋다.
  - web.xml에서 url-pattern에 *.us라고 하는 것은. us라 붙인 모든 것은 설정한 서블릿 클래스로 간다는 뜻이다. 이렇게 한 곳으로 다 모은 다음 그 컨트롤러에서 다시 흐름을 나누게 하는 것이다.
  
  

  

  - 모든 요청을 하나의 컨트롤러로 모으면 컨트롤러에서는 switch ~ case 문을 이용해서 나눠서 맞게 처리해주면 된다.
  - 그러기 위해서는 전체 URI에서 루트 경로를 빼서 흐름을 나누기 위한 기준이 필요하다.
  - 페이지 이동은 case문 하나하나에 써주는 것이 아니라 switch문이 끝나고 마지막에 일괄로 처리해 주면 된다.
  - 페이지를 이동하기 위해서는 어디로 이동하고 어떤 방식으로 이동할지 정해야 하는데 그냥 보내는 것은 상관없지만 DB 처리를 하기 위해 다른 클래스로 갔다가 거기서 원하는 두 가지 정보를 받아 오는 것은 불가능하기에 ActionTo라는 객체를 만들어 그 필드에 어디로 이동하고 어떤 방식으로 이동할지를 설정하고 받아오게 한다.
  
  

  

  - 만약 들어오는 것이 그냥 페이지 이동만 필요한게 아니라 DB 처리가 필요하다면 따로 클래스를 만들어 관리를 한다.
  - 각 처리하는 클래스 안에서는 똑같은 메소드로 ActionTo 객체를 반환하거나 거기서 바로 응답을 하기 때문에 인터페이스로 추상메소드를 만들어 사용한다.
  - 그래서 처리를 위한 클래스는 상속하여 메소드를 사용하면 되고 그 클래스에서 처리를 하기 위해 매개변수로 req, resp를 같이 보낸다.
  - 이제 각 처리하는 클래스에서 페이지의 이동 정보를 객체에 저장해서 반환을 한다.
  - 여기서 주의할 점은 이동 방식 중에 Redirect 방식은 요청 정보를 초기화하면서 다른 페이지로 이동하기 때문에 시스템의 변화가 있으면 무조건 Redirect로 해야 한다.(DB 처리에서 insert, delete, update)

3. Front-Controller 패턴 정리

F-C Model

1. 개발자가 정의한 확장자(.us, .bo, .do, ...)를 페이지 이동 주소에 작성하게 되면 파일이 아니기 때문에 web.xml에 가서 매핑되어 있는 서블릿을 찾는다.

2. 각 URL들(UserJoin.us, UserLogin.us, ...)을 전부 web.xml에 하나씩 매핑해놓게 되면 코드가 길어지기 때문에 *.us 형태로 하나의 서블릿에 매핑을 해 놓는다.(어떤 것이든 .us가 붙은 요청은 하나의 경로로 보내주도록 함)

3. 이러한 경로를 통해 가게되는 서블릿을 프론트 컨트롤러라고 한다.(가장 먼저 요청을 맞이하는 컨트롤러 라서 프론트 컨트롤러)

4. 이 프론트 컨트롤러는 .us 앞에 있는 요청명(UserJoin, UserLogin, ...)으로 어떤 로직을 수행할지 판단하고 분기처리(if문, switch문)를 하게 된다. 프론트 컨트롤러 안에서 모든 비즈니스 로직을 구현해 놓게 되면 마찬가지로 코드가 길어지고 유지보수 및 재사용이 어렵기 때문에 요청별로 따로 Controller(UserJoinAction, UserLoginAction)를 만들어 놓는다.

5. 해당 Action 안에 execute() 메소드를 만들어서 그 내부에 비즈니스 로직을 구현하면 프론트 컨트롤러에서는 그 Action 객체를 만든 후 execute() 메소드를 호출만 하면 된다. 모든 ~~Action에 execute() 메소드를 구현해야 하기 때문에 ~~Action들의 틀을 Action 인터페이스로 만들고 그 안에 추상메소드로 execute()를 선언해 놓으면 각 Action마다 그 인터페이스를 상속받아서 재정의를 하여 구현을 한다.

6, 7, 8. 비즈니스 로직 안에서는 우리가 만든 DAO객체를 통해 DB와 데이터를 주고 받으면서 원하는 결과를 추출하는 로직을 짠다.

9, 10. 비즈니스 로직이 모두 완료되면 어떤 페이지로 이동을 할 것인지, 어떤 방식(forward, redirect)으로 이동할 것인지를 정해서 프론트 컨트롤러로 리턴을 하고 이 때 리턴할 값이 두개이므로 그 둘을 담을 객체로 만들어서 리턴을 해준다. 이 객체의 타입은 ActionTo 타입이다. execute()는 저 결과들 즉 비즈니스 로직을 마친 후의 결과로 판단된 경로와 방식을 통해 ActionTo 타입의 객체를 만들어서 리턴한다.

11, 12. 그 객체를 프론트 컨트롤러에서 일괄적으로 받아서 해석한 후 알맞은 View와 알맞은 방식으로 페이지 이동을 해준다.

 

- 위의 설명처럼 설계과 굉장히 복잡하기 때문에 대규모가 아닌 소규모 프로젝트에 반영했을 때에는 오히려 좋지 않은 결과를 초래한다. 따라서 맞는 목적으로 선택하여 설계해야 함

4. Model2의 페이지 이동 방식

- JSP와 Servlet에서 페이지 이동을 처리할 때 두가지 방식 중 하나를 선택한다.

• Redirect
  서버에게 c.do 요청 -> 서버는 "c.jsp로 갈 수 있는 요청"을 응답 -> 응답받은 것을 이용해서 c.jsp 재요청
  -> c.jsp 응답
  
  - 클라이언트가 요청했을 때 이전의 req, resp 객체는 초기화 된다.
  - 시스템에 변화가 생기는 요청의 경우에는 redirect를 이용한다.
  - 데이터를 보내면서 Redirect를 이용하기 위해서는 세션이나 파라미터 쿠키를 이용하면 된다.
  - Insert, Update, Delete
• Forward
  서버에서 c.do 요청 -> 서버는 처리 결과를 가지고 c.jsp로 전송 -> 전송받은 곳에서 클라이언트에게 응답
  
  - 클라이언트에게 request 객체를 통해 값을 넘겨주어야 할 때 혹은 단순 조회를 요청했을 때 사용한다.
  - Redirect보다 성능이 좋다.
  - Select