MVC 패턴 - 디자인 패턴

MVC 패턴(Model View Controller)

등장 배경

• 너무많은 역할
  • 비즈니스 로직은 서블릿처럼 다른 곳에서 처리하고, HTML은 화면(View)을 그리는 일에 집중하기 위해 만들었다.
  • 서블릿으로 개발할 때, 뷰(View)화면을 위한 HTML을 만드는 작업이 자바 코드에 섞여서 지저분하고 복잡해진다.
  • 비즈니스 로직을 호출하는 부분에 변경이 발생해도 해당 코드를 손대야하고, UI를 변경할 일이 있어도 비즈니스 로직이 함께 있는 해당 파일을 수정해야한다.
• 변경의 라이프 사이클
  • 비즈니스 로직과 UI 사이에 변경의 라이프 사이클이 다르다.
  • 대부분의 경우 서로에게 영향을 주지 않는다.
  • 변경의 라이프 사이클이 다른 부분을 하나의 코드로 관리하는 것은 유지보수에 좋지 않다.
• 기능 특화
  • 특히 JSP 같은 뷰 템플릿은 화면을 렌더링 하는데 최적화 되어 있기 때문에 이 부분 업무만 담당하는 것이 가장 효과적이다.

의미

• 비즈니스 로직과 UI를 한꺼번에 관리하던 것을 컨트롤러(Controller), 뷰(View), 모델(Model)이라는 영역으로 서로 역할을 나눈 것을 말한다. 웹 애플리케이션은 보통 이 MVC패턴을 사용한다.
• 컨트롤러 : HTTP 요청을 받아서 파라미터를 검증하고, 비즈니스 로직을 실행한다. 그리고 뷰에 전달할 결과 데이터를 조회해서 모델에 담는다.
• 뷰 : 모델에 담겨있는 데이터를 사용해서 화면을 그리는 일에 집중한다.
• 모델 : 뷰에 출력할 데이터를 담아둔다. 뷰가 필요한 데이터를 모두 모델에 담아서 전달해주는 덕분에 뷰는 비즈니스 로직이나 데이터 접근을 몰라도 되고, 화면을 렌더링 하는 일에 집중할 수 있다.

참고

• 컨트롤러에 비즈니스 로직을 둘 수도 있지만, 이렇게 되면 컨트롤러가 너무 많은 역할을 담당한다. 그래서 일반적으로 비즈니스 로직은 서비스(Service)라는 계층을 별로도 만들어서 처리
• 컨트롤러에서 비즈니스 로직이 있는 서비스를 호출하는 담당을 함
• 비즈니스 로직을 변경하면 비즈니스 로직을 호출하는 컨트롤러의 코드도 변경 될 수 있다.

 

Redirect vs Forward

• Redirect 
  • 실제 클라이언트(웹 브라우저)에 응답이 갔다가, 클라이언트가 redirect 경로로 다시 요청함
  • 클라이언트가 인지할 수 있고, URL도 실제로 변경됨
• Forward
  • 내부에서 일어나느 호출이기 떄문에 클라이언트가 전혀 인지하지 못함.

 

단점

• 뷰는 화면을 그리는 역할에 충실한 덕분에, 코드가 깔끔하고 직관적이고, 모델에서 필요한 데이터를 꺼내고 화면을 만들면 된다. 하지만, 컨트롤러는 중복이 많고 필요하지 않는 코드들이 많아진다.
• 포워드 중복
  • View로 이동하는 코드가 항상 중복 호출돼야 한다. 해당 부분을 메서드로 공통화해도 되지만, 해당 메서드도 항상 직접 호출해야함
• ViewPath의 중복
• 사용하지 않는 코드가 발생함
  • HttpServletRequest, HttpServletResponse와 같은 코드가 항사 사용되지 않지만 항상 필요하다.
  • 그리고 위의 코드들은 테스트 케이스를 작성하기 어렵다.
• 공통처리가 어려움
  • 기능이 복잡해질 수록 컨트롤러에서 고통으로 처리해야하는 부분이 점점 더 많이 증가함.
  • 메서드로 뽑아내도 결국, 메서드를 항상 호출해야하고, 실수로 호출하지 않으면 문제가 됨(호출하는 것 자체도 중복)

 

프론트 컨트롤러(Front Controller) 패턴의 등장

• MVC패턴의 공통 처리가 어려운 문제를 해결하기 위해서 도입됨.
• 입구를 하나로 만드는 패턴
• https://conpulake.tistory.com/253

FrontController 패턴 - 디자인 패턴