[BE 기초] 4. MVC Architecture

MVC 디자인 패턴

 

MVC(Model-View-Controller) 디자인 패턴은 애플리케이션을 세 가지 역할로 분리하여 개발하는 방법론을 의미한다. 

 

• Model(모델) : 데이터와 비즈니스 로직(Service)을 처리 
  • 필요 시 DB와 연동되어 사용(DAO가 Model에 포함됨)
• View(뷰) : 사용자에게 보여지는 UI 부분
  • 데이터를 시각적으로 표현하는 역할 
• Controller(컨트롤러) : 사용자의 요청을 받으며 Model과 View를 연결 

 

MVC Pattern

 

왜 MVC 패턴이 등장했을까? 이전 포스팅에서 본 Servlet이나 JSP만으로 모든 비즈니스 로직과 뷰를 처리한다고 생각해 보자. 비즈니스 로직이 짧더라도 화면을 구성하기 위한 코드가 많아져 가독성이 떨어지고 유지보수가 어려워질 수 있다. 또한, 로직을 변경해야 할 때 뷰와 함께 있는 파일을 수정해야 하므로, 변경 범위가 넓어진다.

 

보통 UI와 비즈니스 로직은 라이브 사이클이 다르며, 각각의 수정이 서로에게 영향을 주지 않는 경우가 많다. 그런데 기존 방식에서는 이 둘이 강하게 결합되어 있어, UI를 변경하면 비즈니스 로직도 영향을 받고, 반대로 로직을 수정하면 UI까지 함께 수정해야 하는 비효율적인 상황이 발생했다. 따라서 MVC 패턴에서는 역할을 Model(비즈니스 로직), View(화면), Controller(입력 처리 및 흐름 제어)로 분리하는 것이다. 

 

이렇듯 분리된 역할로 인해 독립적인 개발이 가능하고 유지보수가 용이해지며, 코드의 가독성, 재사용성을 향상시킬 수 있다. 

 

Java Web에서는 MVC 패턴과 관련하여 Model 1 방식과 Model 2 방식이 존재한다. Model 1 방식은 JSP 중심의 구조이며, Model 2 방식은 MVC 패턴을 엄격히 적용한 구조이다. 

 

 

 

Model 1

 

Model 1 방식에서는 JSP가 클라이언트 요청에 대한 로직 처리와 view에 대한 처리를 모두 수행한다. 즉, JSP가 View와 Controller 역할을 전부 하게 된다. 

 

Model 1 방식

 

이러한 방식은 구조가 단순하여 개발이 빠르고 직관적이라는 장점이 있다. 하지만 유지보수가 어렵고 확장성 역시 좋지 않다. 

 

 

 

Model 2

 

Model 2 방식에서는 클라이언트의 요청을 Servlet이 받게 된다. Servlet은 요청을 받아 View(JSP)로 보여줄 것인지, Model로 보내줄 것인지 정하여 전송해준다. Model은 실질적인 기능의 부분을 담당하게 된다. 

 

Model 2 방식

 

이러한 방식은 구조가 명확하고 유지보수가 용이하며, 확장성 역시 좋다. 다만 Model 1에 비해 구조가 복잡하고 개발이 어려워 초기 개발 속도가 느려질 수 있다. 

 

대부분의 웹은 Model 2를 따르며 Spring MVC 또한 Model 2를 따른다. 

 

 

 

웹 컴포넌트 호출 

 

MVC 패턴의 Controller와 View에서는 어떻게 요청을 전달하고 페이지 흐름을 제어할까? Controller에서 View를 호출하기 위해, 주로 forward 혹은 redirect 방식을 사용한다.

 

• forward : 서버 내의 다른 리소스(Servlet, JSP 페이지, HTML 파일 등)로 요청을 전달하는 방법  
  • RequestDispatcher.forward() 사용 
  • 최초 발생한 request와 response 전달
  • 클라이언트 입장에서는 호출 1번(최초 요청한 URL이 변경되지 않음, 처리 위임 사실을 모름)
  • 같은 context 내에 있는 리소스만 사용 가능
  • redirect보다 속도 빠름
• redirect : 요청을 브라우저로 전달하여 다른 웹 애플리케이션을 요청하는 방법 
  • response.sendRedirect() 사용
  • 최초 요청과 관련 없는 request와 response를 새로 생성
  • 클라이언트 입장에서는 호출 2번(URL의 변경이 있음)
  • 다른 context, 다른 서버로 변경 가능

 

forward는 시스템에 변화가 생기지 않는 단순 조회 요청(글 목록 보기, 검색 등)에 사용하기 적합하다. 변화가 생기는 요청을 forward로 처리하게 되면 사용자가 새로 고침을 할 경우 동일한 요청을 반복하게되어 중복된 데이터 처리나 의도하지 않은 동작이 발생할 수 있다. 따라서 시스템에 변화가 생기는 요청(회원가입, 글쓰기 등)의 경우에는 redirect를 사용하는 것이 바람직하다. 

 

중복 요청의 경우 예시를 좀 더 자세히 들어보자면, 사용자의 회원가입 요청을 forward로 처리하는 상황을 생각해 보자.

 

1. 사용자가 회원가입 버튼을 클릭하여 POST 방식으로 요청을 보낸다.
2. 서버는 이 요청을 처리하고 회원가입을 완료한 후, forward 방식으로 회원가입 성공 페이지로 이동시킨다. 
3. 사용자가 회원가입 성공 페이지에서 새로 고침을 누르면, 서버는 동일한 POST 요청을 다시 처리한다! 
4. 이때 중복 회원가입이 발생하는 등 예기치 못한 동작이 일어날 수 있다. 

 

forward 방식에서 클라이언트의 URL이 변경되지 않고, request의 response 객체가 그대로 사용되므로, 동일한 요청이 처리되는 것이다. redirect를 사용하면 새로운 요청을 새로운 request와 response 객체로 보내므로 다시 같은 요청이 서버로 전달될 일이 발생하지 않는다.