MVC 패턴의 등장

서블릿, JSP의 한계

  • 서블릿에서 View 화면을 구현하는 것은 HTML 코드가 java 코드에 섞여서 복잡하고 지저분해짐
  • JSP를 이용하여 이를 해결하였으나, 비즈니스 로직이 JSP에 너무 많이 노출되어 있음
    • JSP의 역할이 너무 많음 => 유지보수가 지옥과 같아짐
    • 로직과 뷰는 서로 둘 사이 변경 라이프 사이클이 다름
    • 대부분 서로 영향을 주지 않는데 굳이 한 곳에 집중하게 돼있으면 유지보수 헬

MVC 패턴

MVC

  • 비즈니스 로직과 View를 나누어 각자의 역할에 충실한 패턴
  • 하나의 서블릿이나 JSP가 아닌, Controller와 View라는 영역으로 서로 역할을 분담
  • MVC (Model View Controller)
    • Model
      • View에 출력할 데이터를 담아둠
      • 필요한 데이터를 모두 Model에 담아서 전달 => View는 로직이나 데이터 접근을 몰라도 됨
    • View
      • Model에 담겨있는 데이터를 사용해서 화면을 렌더링하는데 집중 (HTML)
    • Controller
      • HTTP 요청을 받아서 파라미터를 검증, 비즈니스 로직을 실행 (Service 호출)
      • View에 전달할 결과 데이터를 조회하여 모델에 담음
    • 비즈니스 로직을 Controller에 담아도 되지만, Controller의 기능이 너무 커짐

MVC 패턴의 한계

  • Controller는 중복이 많고 ,필요치 않은 코드들도 많음
  • View로 이동하는 코드가 항상 중복 호출 (포워드 중복)
  • ViewPath에 중복 (View를 jsp로 안 쓴다? 확장자 전부 다 바꿔줘야 함…)
  • 사용하지 않는 코드가 많음
  • 공통 처리가 어려움
    • 기능이 복잡해질수록 Controller에서 공통으로 처리해야 하는 부분이 많아짐
    • 수문장 역할을 하는 기능 필요 => Front Controller (입구를 하나로 만듬)
    • Front Controller 도입 : Controller 호출 전에 먼저 공통 기능을 처리



인프런 - 김영한님의 Spring MVC 강의를 정리한 내용입니다.


김영한님 인프런 강의

댓글남기기

참고