[모각코 9주차] 결과 (16:00 ~ 19:00)

서블릿과 JSP의 한계

• 서블릿으로 개발하면 뷰 화면을 만들기 위한 HTML을 만드는 작업이 자바 코드에 섞여 지저분하고 복잡
• JSP를 사용하여 뷰를 생성하는 HTML 작업을 깔끔하게 하고, 중간중간 자바 코드가 필요한 부분에만 자바 코드를 적용
• 하지만 JSP에 자바코드, 데이터를 조회하는 리포지토리 등 다양한 코드가 모두 jsp에 노출되어 jsp가 너무 많은 역할을 하게 된다.
• 그러므로 JSP는 목적에 맞게 화면을 그리는 일에만 집중하도록 하는 MVC 패턴이 등장했다.

MVC 패턴

• 등장 배경
  • 너무 많은 역할
    • 하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링을 모두 처리하면, 너무 많은 역할을 하게되어 유지보수가 어려워진다.
    • UI에 변경이 일어나도 비즈니스 로직을 같이 수정해야할 수 있다.
  • 변경의 라이프 사이클
    • UI와 비즈니스 로직은 변경의 라이프 사이클이 다르다.
    • UI를 수정하는 부분과 비즈니스 로직을 수정해야하는 일은 각각 다르게 발생할 가능성이 높고, 대부분 서로 영향을 주지 않는다.
    • 이렇게 변경의 라이프 사이클이 다른 부분을 하나의 코드로 관리하는 것은 유지보수하기 좋지 않다.
  • 기능 특화
    • JSP같은 뷰 템플릿은 화면을 렌더링 하는데 최적화 되어 있기 때문에 이 부분의 업무만 담당하는 것이 좋다.
• Model View Controller
  • Model : 뷰에 출력할 데이터를 담아둔다. 뷰가 필요한 데이터를 모두 모델에 담아서 전달해주는 덕분에 뷰는 비즈니스 로직이나 데이터 접근을 알 필요가 없다.
  • View : 모델에 담겨있는 데이터를 사용해서 화면을 그리는 일에 집중한다. 여기서는 HTML을 생성하는 부분을 말한다.
  • Controller : HTTP 요청을 받아 파라미터를 검증하고, 비즈니스 로직을 실행한다. 그리고 뷰에 전달할 결과 데이터를 조회하여 모델에 담는다.
• 
• MVC 패턴 적용
  • 서블릿을 컨트롤러로 사용하고, JSP를 뷰로 사용하는 MVC 패턴이다.
  • Model은 HttpServletRequest 객체를 사용한다. request는 내부에 데이터 저장소를 가지고 있는데, request.setAttribute, request.getAttribute를 사용하여 데이터를 보관하고, 조회할 수 있다.
  
  • dispatcher.forward() : 다른 서블릿이나 JSP로 이동할 수 있는 기능이다. 서버 내부에서 다시 호출이 발생한다.
    • 포워드는 서버 내부에서 일어나는 일이므로 클라이언트가 알 수 없다.
    • 리다이렉트는 클라이언트에 응답이 갔다가 클라이언트가 다시 리다이렉트 경로로 요청하게 되므로 인지할 수 있다. URL 경로도 실제로 변경된다.
  • /WEB-INF : 이 경로안에 JSP가 있으면 외부에서 직접 JSP를 호출할 수 없다. MVC 패턴에서는 컨트롤러를 통해 JSP를 호출해야한다
• MVC 패턴의 한계
  • MVC 덕분에 컨트롤러, 뷰를 명확하게 구분할 수 있었다.
  • 하지만 중복이 많고 필요하지 않은 코드들이 많이 보인다.
  • 포워드 중복
    • View로 이동하는 코드가 항상 중복 호출되어야 한다. 이 부분을 메서드로 공통화할 수 있지만 해당 메서드도 항상 직접 호출해야한다.
  • ViewPath에 중복
    • prefix와 suffix가 항상 중복된다.
  • 사용하지 않는 코드
    • 사용하지 않는 코드가 작성될 때가 있다.
  • 공통 기능의 처리가 어렵다.
    • 기능이 복잡해질수록 컨트롤러에서 공통으로 처리해야하는 부분이 점점 더 많이 증가하게 된다.
• 해결
  • 프론트 컨트롤러 패턴을 도입한다.

서블릿과 JSP의 한계

• 서블릿으로 개발하면 뷰 화면을 만들기 위한 HTML을 만드는 작업이 자바 코드에 섞여 지저분하고 복잡
• JSP를 사용하여 뷰를 생성하는 HTML 작업을 깔끔하게 하고, 중간중간 자바 코드가 필요한 부분에만 자바 코드를 적용
• 하지만 JSP에 자바코드, 데이터를 조회하는 리포지토리 등 다양한 코드가 모두 jsp에 노출되어 jsp가 너무 많은 역할을 하게 된다.
• 그러므로 JSP는 목적에 맞게 화면을 그리는 일에만 집중하도록 하는 MVC 패턴이 등장했다.

MVC 패턴

• 등장 배경
  • 너무 많은 역할
    • 하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링을 모두 처리하면, 너무 많은 역할을 하게되어 유지보수가 어려워진다.
    • UI에 변경이 일어나도 비즈니스 로직을 같이 수정해야할 수 있다.
  • 변경의 라이프 사이클
    • UI와 비즈니스 로직은 변경의 라이프 사이클이 다르다.
    • UI를 수정하는 부분과 비즈니스 로직을 수정해야하는 일은 각각 다르게 발생할 가능성이 높고, 대부분 서로 영향을 주지 않는다.
    • 이렇게 변경의 라이프 사이클이 다른 부분을 하나의 코드로 관리하는 것은 유지보수하기 좋지 않다.
  • 기능 특화
    • JSP같은 뷰 템플릿은 화면을 렌더링 하는데 최적화 되어 있기 때문에 이 부분의 업무만 담당하는 것이 좋다.
• Model View Controller
  • Model : 뷰에 출력할 데이터를 담아둔다. 뷰가 필요한 데이터를 모두 모델에 담아서 전달해주는 덕분에 뷰는 비즈니스 로직이나 데이터 접근을 알 필요가 없다.
  • View : 모델에 담겨있는 데이터를 사용해서 화면을 그리는 일에 집중한다. 여기서는 HTML을 생성하는 부분을 말한다.
  • Controller : HTTP 요청을 받아 파라미터를 검증하고, 비즈니스 로직을 실행한다. 그리고 뷰에 전달할 결과 데이터를 조회하여 모델에 담는다.
• 
• MVC 패턴 적용
  • 서블릿을 컨트롤러로 사용하고, JSP를 뷰로 사용하는 MVC 패턴이다.
  • Model은 HttpServletRequest 객체를 사용한다. request는 내부에 데이터 저장소를 가지고 있는데, request.setAttribute, request.getAttribute를 사용하여 데이터를 보관하고, 조회할 수 있다.
  
  • dispatcher.forward() : 다른 서블릿이나 JSP로 이동할 수 있는 기능이다. 서버 내부에서 다시 호출이 발생한다.
    • 포워드는 서버 내부에서 일어나는 일이므로 클라이언트가 알 수 없다.
    • 리다이렉트는 클라이언트에 응답이 갔다가 클라이언트가 다시 리다이렉트 경로로 요청하게 되므로 인지할 수 있다. URL 경로도 실제로 변경된다.
  • /WEB-INF : 이 경로안에 JSP가 있으면 외부에서 직접 JSP를 호출할 수 없다. MVC 패턴에서는 컨트롤러를 통해 JSP를 호출해야한다.
• MVC 패턴의 한계
  • MVC 덕분에 컨트롤러, 뷰를 명확하게 구분할 수 있었다.
  • 하지만 중복이 많고 필요하지 않은 코드들이 많이 보인다.
  • 포워드 중복
    • View로 이동하는 코드가 항상 중복 호출되어야 한다. 이 부분을 메서드로 공통화할 수 있지만 해당 메서드도 항상 직접 호출해야한다.
  • ViewPath에 중복
    • prefix와 suffix가 항상 중복된다.
  • 사용하지 않는 코드
    • 사용하지 않는 코드가 작성될 때가 있다.
  • 공통 기능의 처리가 어렵다.
    • 기능이 복잡해질수록 컨트롤러에서 공통으로 처리해야하는 부분이 점점 더 많이 증가하게 된다.
• 해결
  • 프론트 컨트롤러 패턴을 도입한다