[CS] MVC 패턴 (Model - View - Controller)

서론

웹개발을 공부하면서 또는 면접을 보러 가면 MVC패턴에 대해 질문을 받을 때가 있습니다.

MVC 패턴에 대해 자세히 알기 위해 공부하면서 정리해 봅니다.

 

MVC패턴이란?

MVC란 Model-View-Controller의 약자로 애플리케이션을 세 가지 역할로 구분한 개발 방법론입니다. 아래의 그림처럼 사용자가 Controller를 조작하면 Controller는 Model을 통해 데이터를 가져오고 그 데이터를 바탕으로 View를 통해 시각적 표현을 제어하여 사용자에게 전달하게 됩니다. 이러한 패턴을 성공적으로 사용하면, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시작적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있게 됩니다.

1. 사용자가 웹사이트에 접속 (Uses)
2. Controller는 사용자가 요청한 웹페이지를 서비스하기 위해서 모델을 호출 (Manipulates)
3. Model은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후 그 결과를 Return
4. Controller는 Model이 리턴한 결과를 View에 반영 (Updates)
5. 데이터가 반영된 View는 사용자에게 보여짐 (Sees)

 

 모델 (Model)

데이터를 가진 객체를 모델이라고 지칭합니다. 데이터는 내부의 상태에 대한 정보를 가질 수도 있고, 모델을 표현하는 이름 속성으로 가질 수 있습니다. 모델의 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보합니다. 이와 같은 통보를 통해 뷰는 최신의 결과를 보여줄 수 있고, 컨트롤러는 모델의 변화에 따른 적용 가능한 명령을 추가, 제거, 수
정할 수 있습니다.

 

모델의 규칙

1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야만 합니다.

• 즉, 화면안의 박스에 글자가 표현된다면, 박스의 화면 위치 정보, 박스의 크기 정보, 글자 내용, 글자의 위치, 글자의 포맷 정보 등을 가지고 있어야 합니다. 

2. 뷰나 컨트롤러에 대해서 어떠한 정보도 알지 말아야 합니다.

• 데이터 변경이 일어났을 때 모델에서 화면 UI를 직접 조정해서 수정할 수 있도록 뷰를 참조하는 내부 속성값을 가지면 안 됩니다.

3. 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 합니다

• 모델의 속성 중 텍스트 정보가 변경이 된다면, 이벤트를 발생시켜 누군가에게 전달해야 하며, 누군가 모델을 변경하도록 요청하는 이벤트를 보냈을 때, 이를 수신할 수 있는 처리 방법을 구현해야 합니다. 또한 모델은 재사용 가능해야 하며 다른 인터페이스에서도 변하지 않아야 합니다.

 

뷰 (View)

View는 클라이언트 측 기술은 HTML/CSS/Javascript들을 모와둔 컨테이너입니다. 사용자가 볼 결과물을 생성하기 위해 모델로부터 정보를 얻어옵니다.

 

뷰의 규칙

1. 모델이 가지고 있는 정보를 따로 저장해서는 안됩니다

• 화면에 글자를 표시하기 위해, 모델이 가지고 있는 정보를 전달받게 될 텐데, 그 정보를 유지하기 위해 임의의 뷰 내부에 저장하면 안 됩니다. 단순히 박스를 그리라는 명령을 받으면, 화면에 표시하기만 하고 그 화면을 그릴 때 필요한 정보들은 저장하면 안됩니다.

2. 모델이나 컨트롤러와 같이 다른 구성 요소를 몰라야 합니다.

• 모델과 같은 자기 자신의 빼고는 다른 요소는 참조하거나 어떻게 동작하는지 알아서는 안됩니다. 그냥 뷰는 데이터를 받으면 화면에 표시해 주는 역할만 가진다고 보면 됩니다.

3. 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 합니다.

• 모델과 같이 변경이 일어났을 때 이른 누군가에게 변경을 알려줘야 하는 방법을 구현해야 합니다. 뷰에서는 화면에서 사용자가 화면에 표시된 내용을 변경하게 되면 이를 모델에게 전달해서 모델을 변경해야 할 것이다. 그 작업을 하기 위해 변경 통지를 구현합니다.
• 그리고 재사용가능하게끔 설계를 해야 하며 다른 정보들을 표현할 때 쉽게 설계를 해야 합니다.

 

컨트롤러 (Controller)

사용자가 접근한 URL에 따라 사용자의 요청사항을 파악한 후에 그 요청에 맞는 데이터를 Model을 의뢰하고, 데이터를 View에 반영해서 사용자에게 알려줍니다.

모델에 명령을 보냄으로써 뷰의 상태를 변경할 수 있음 ➡ (워드에서 문서 편집)
컨트롤러가 관련된 모델에 명령을 보냄으로써 뷰의 표시 방법을 바꿀 수 있음 ➡ (문서를 스크롤하는 것)

 

컨트롤러의 규칙

1. 모델이나 뷰에 대해서 알고 있어야 합니다.

• 모델이나 뷰는 서로의 존재를 모르고, 변경을 외부로 알리고, 수신하는 방법만 가지고 있는데 이를 컨트롤러가 중재하기 위해 모델과 그에 관련된 뷰에 대해서 알고 있어야 합니다.

2. 모델이나 뷰의 변경을 모니터링해야 합니다.

• 모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에게 통지를 해야 합니다.
• 또한, 애플리케이션의 메인 로직은 컨트롤러가 담당하게 됩니다.

 

MVC 패턴 방식

Model 1.

모델 1 방식은 Controller 영역에 View 영역을 같이 구현하는 방식이며, 사용자의 요청을 JSP가 전부 처리합니다. 요청을 받은 JSP는 JavaBean Service Class를 사용하여 웹브라우저 사용자가 요청한 작업을 처리하고 그 결과를 출력합니다.

 

 

Model 2.

모델 2 방식은 웹브라우저 사용자의 요청을 서블릿이 받고 서블릿은 해당 요청으로 View로 보여줄 것인지 Model로 보낼 것인지를 판단하여 전송합니다. 또한 모델 2 방식의 경우 HTML 소스와 JAVA소스를 분리해 놓았기 때문에 모델 1 방식에 비해 확장시키기도 쉽고 유지보수 또한 쉽습니다.

 

Model 1 vs Model 2

	Model 1	Model 2
장점	빠르고 쉽게 개발 가능	디자이너와 개발자의 분업이 가능하며 유지보수 및 확장이 쉬움
단점	JSP파일이 너무 비대해지며 Controller와 View가 혼재하므로 향후 유지보수에 어려움	설계가 어려우며 개발 난이도가 높음

>> Model 1 방식으로 웹서비스를 개발하는 사례는 백엔드와 프론트엔드의 역할 분담이 모호해져 협업이 쉽지 않으며 실제 서비스들 중에서 거의 없다고 봐도 무방합니다. 

 

MVC패턴을 사용하는 이유?

• 사용자가 보는 페이지, 데이터처리, 그리고 이 2가지를 중간에서 제어하는 컨트롤, 이 3가지로 구성되는 하나의 애플리케이션을 만들면 각각 맡은 바에만 집중을 할 수 있게 됩니다.
• 서로 분리되어 각자의 역할에 집중할 수 있게끔 하여 개발을 하고 그렇게 애플리케이션을 만든다면, 유지보수성, 애플리케이션의 확장성, 그리고 유연성이 증가하고, 중복코딩이라는 문제점 또한 사라지게 되는 것입니다.