서블릿과 JSP의 한계 

 

서블릿으로 개발할때는 뷰화면을 위한 HTML을 만드는 작업이 자바 코드에 섞여서 지저분함 

JSP를 사용하면 뷰를 생성할때 HTML작업을 깔끔하게 할 수 있는 장점이 있다. 하지만 JSP에도 단점이 존재하는데 

코드 상위에는 비즈니스 로직이 들어가고 나머지 하위만 결과를 HTML로 보여주기 위한 뷰 영역이다 

 

즉, JAVA코드, 리포지토리 등이 모두 JSP에 노출되어 있다. 

 

 

MVC 등장! 

위의 방식은 유지보수가 어렵다. 

JSP는 화면을 랜더링 하는데 최적화이기 때문에 이 부분의 업무만 하는게 낫다. 

 

컨트롤러: HTTP요청을 받아서 파라미터 검증 후 비즈니스 로직 실행 -> 뷰에 전달할 결과 데이터를 조회한후 모델에 담음

 

모델: 뷰에 출력할 데이터를 담는곳, 뷰가 데이터를 전달해주는 덕분에 뷰는 비즈니스 로직이나 데이터 접근을 몰라도 된다. 

 

: 모델에 담겨있는 데이터를 사용해서 화면을 그리는 일에 집중 

 

 

redirect vs forward 

리다이렉트는 실제 클라이언트(웹 브라우저)에 응답이 나갔다가, 클라이언트가 redirect경로로 다시 요청함. 따라서 클라이언트가 인지할 수 있고 URL 경로도 실제로 변경된다. 

 

포워드는 서버 내부에서 일어나는 호출이기 때문에 클라이언트가 인지 불가. 

 

@WebServlet(name = "mvcMemberSaveServlet", urlPatterns = "/servlet-mvc/members/save")
public class MvcMemberSaveServlet extends HttpServlet {
private MemberRepository memberRepository = MemberRepository.getInstance();

@Override
protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    String username = request.getParameter("username");
    int age = Integer.parseInt(request.getParameter("age"));
    Member member = new Member(username, age);
    System.out.println("member = " + member);
    memberRepository.save(member);
    
    //Model에 데이터를 보관한다.
    request.setAttribute("member", member);
    
    String viewPath = "/WEB-INF/views/save-result.jsp";
    RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
    dispatcher.forward(request, response);
	}
}

 

Request가 제공하는 setAttribute()를 사용하면 request 객체에 데이터를 보관해서 뷰에 전달할 수 있다. 

뷰는 request.getAttribute()를 사용해서 데이터를 꺼낸다 

 

jstl와 jsp의 ${} 문법을 사용해서 데이터를 사용할 수 있다. 

 

MVC한계

MVC덕분에 컨트롤러의 역할과 뷰를 렌더링 하는 역할을 명확하게 구분가능

 

단점: 

포워드 중복 ->

RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);

 

ViewPath중복 ->

 

String viewPath = "/WEB-INF/views/new-form.jsp";

사용하지 않는 코드 ->

HttpServletRequest request, HttpServletResponse response

공통처리가 어렵다 -> 기능이 복잡해질수록 컨트롤러에서 공통으로 처리해야 하는 부분이 점점 더 많이 증가할 것이다. 단순히 공통 기능을 메서드로 뽑으면 될 것 같지만, 결과적으로 해당 메서드를 항상 호출해야함, 실수로 호출하지 않으면 문제가 됨 

 

-> 정리하면 공통처리가 어렵다

+ Recent posts