MVC 패턴 톺아보기

MVC 패턴의 MVC는 Model View Controller의 약자이다.

Model

 데이터와 비즈니스 로직을 처리. 사용자가 편집하길 원하는 모든 데이터를 의미.

• 정보 및 데이터 부분을 의미한다.
• 이는 Controller에게 받은 데이터를 조작(가공)하는 역할을 수행한다고 볼 수 있다.
• 즉, 데이터와 관련된 부분을 담당하며 값과 기능을 가지는 객체라고 보면 된다.

규칙

1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
2. View나 Controller에 대해서 어떤 정보도 알지 말아야 한다.
3. 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.

View

사용자에게 보여지는 UI 부분. 즉, 데이터를 시각적으로 표현하는 역할.

• View는 입력값이나 체크박스 등과 같은 사용자 인터페이스 요소를 나타낸다.
• 이는 Controller에게 받은 Model의 데이터를 사용자에게 시각적으로 보여주기 위한 역할을 수행한다.
• 사용자에게 보여지는 화면이라고 볼 수 있다.

규칙

1. Model이 가지고 있는 정보를 따로 저장해서는 안된다.
2. Model이나 Controller를 알고 있을 필요가 없다.
3. 변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다.

Controller

사용자의 입력을 처리하고, 모델과 뷰를 연결하는 역할.

• Controller는 Model과 View 사이에서 데이터 흐름을 제어한다.
• 사용자 요청을 파악하고 적절한 Method를 호출하여 Service에서 비즈니스 로직을 처리한다.
• 이 후 결과를 Model에 저장하여 View에게 전달하는 역할을 수행한다.
• 결국 Controller는 Model과 View의 역할을 분리하는 중요한 요소이다.

규칙

1. Model이나 View에 대해서 알고 있어야 한다.
2. Model이나 View의 변경을 모니터링 해야 한다.

 

Model, View, Controller의 관계

• 사용자의 Request(요청)를 Controller가 받는다.
• Controller는 Service에서 비즈니스 로직을 처리한 후 결과를 Model에 담는다.
• Model에 저장된 결과를 바탕으로 시각적 요소 출력을 담당하는 View를 제어하여 사용자에게 전달한다.

 

MVC 패턴의 이점

1. 컴포넌트의 명확한 역할 분리로 인해 서로간의 결합도를 낮출 수 있다.

MVC 패턴으로 구현된 소프트웨어나 애플리케이션은 Model, View, Controller 3가지 컴포넌트로 명확하게 구분되기 때문에 Model은 데이터 및 비즈니스 로직을 담당하고, View는 사용자 인터페이스를 표현하며, Controller는 사용자 요청을 처리하기 위해 Model과 View의 흐름을 제어한다. 이러한 점을 통해 각각의 컴포넌트는 자신이 맡은 역할만 수행한 후 다른 컴포넌트로 결과만 넘겨주면 되기 때문에 서로간의 결합도를 낮출 수 있다.

 

2. 코드의 재사용성 및 확장성을 높일 수 있다.

개발한 Model과 Controller는 여러 View에서 재사용할 수 있고, View의 경우도 다른 Model과 함께 재사용할 수 있으므로 개발 시간을 단축하고 중복 코드를 줄이는데 많은 도움을 줄 수 있다. 이로 인해 기능이나 모듈별로 코드를 분리하여 하나의 파일에 코드가 모이는 것을 최소화하여 작성한 코드의 가독성 및 확장성, 그리고 재사용성을 증가시킬 수 있다.

 

3. 서비스를 유지보수하고 테스트하는데 용이해진다.

변경이 필요한 부분을 보다 쉽게 식별 및 파악할 수 있고, 수정이나 확장할 경우 해당 부분에만 집중하여 개발할 수 있어서 다른 부분에는 영향을 덜 주게 된다. 이를 통해 변경에 따른 유지보수 비용을 줄일 수 있다. 또한, Model, View, Controller를 개별적으로 테스트하기 쉽기 때문에 컴포넌트의 동작을 테스트하기 위한 단위테스트 및 통합 테스트 코드를 개발하는데 수월하다.

 

4. 개발자 간의 커뮤니케이션 효율성을 높일 수 있다.

Model, View, Controller의 역할이 분리되어 있기 때문에 개발자들 간의 협업 과정 속에서도 담당한 역할에 대한 작업을 수행하면 되기 때문에 코드 충돌을 미리 방지하기가 쉽다. 그리고 분리된 역할마다 개발자가 배정되어 개발 업무를 수행하기 때문에 제 3자인 개발자가 의견이나 피드백을 전달하기 좋은 구조를 제공하며, 보다 쉽게 새로운 요구사항을 도출할 수 있다.

 

요약

• 코드의 재사용성과 코드 관리가 용이하다. 각 컴포넌트들이 독립적으로 작동하기 때문에, 개발과 유지 보수가 편리해진다.
• 코드의 분리로 인해 디버깅이 더 쉬워진다. 오류가 발생하면 해당 영역만 확인하면 되기 때문이다.
• 개발자와 디자이너가 동시에 작업을 진행할 수 있다. 뷰는 사용자 인터페이스에 집중하고, 모델과 컨트롤러는 비즈니스 로직에 집중하기 때문이다.

 

MVC 패턴의 단점

1. Model과 View의 의존성을 완전히 분리시킬 수 없다.

일반적으로 View는 Controller와 연결되어 화면을 구성하게 된다. 그렇기에 자연스럽게 Controller는 여러 개의 View를 가질 수 있게 된다. 이 때, Model은 Controller를 통해서 View와 연결된다. 즉, Controller에 의해 하나의 View에 연결되는 Model도 여러 개가 될 수 있다는 말이다.

결국 복잡한 구조의 애플리케이션일수록 하나의 Controller에 다수의 View와 Model이 복잡하게 연결되어 서로간의 의존성이 커지는 상황이 발생할 수 있다. 하나의 Controller에 하나의 View와 하나의 Model만 연결하면 되는거 아니야? 라고 말할수도 있겠지만, 요구사항에 따라서 Controller-View-Model의 비중을 1:1:1로 둘 수 없는 상황도 있을 수 있다.

 

2. 컨트롤러의 역할이 과도하게 커진다면 Massive-View-Controller 현상을 피할 수 없다.

위 사진처럼 규모가 복잡하고 큰 서비스 및 프로그램의 경우는 하나의 Controller에도 수많은 View와 Model이 연결되어 있기 때문에 자연스럽게 컨트롤러의 부하가 커지게 된다. 이를 Massive-View-Controller 현상이라고 한다.

Massive-View-Controller(대규모 MVC 어플리케이션)란?MVC 패턴에서 컨트롤러의 역할이 과도하게 커지고 복잡해지는 상황을 지칭한다. 이는 주로 대규모 애플리케이션에서 발생할 수 있으며, 코드의 비대화, 재사용성 및 확장성 저하, 유지보수성 하락 및 테스트 용이성 저하 등의 문제를 야기할 수 있다.

이로 인해 Controller의 부담이 커졌으니 당연하게도 엮여있는 Model과 View를 변경하는데도 굉장히 많은 비용이 들어갈 것이고, 변경하다가 다양한 Side-Effect를 불러오게 될 수도 있을 것이라고 생각한다. 그로인해 역설적이게도 장점이었던 유지보수성이 안좋아질수도 있다.

 

요약

• 설계 시간이 오래 걸릴 수 있다. 처음부터 MVC 패턴을 적용하기 위해선 초기 설계 시간이 다소 필요하다.
• 간단한 애플리케이션에 적용할 경우 코드가 복잡해질 수 있다. MVC 패턴은 크고 복잡한 프로젝트에 적합하며, 간단한 프로젝트에는 오버킬이 될 수 있다.

MVC를 지키면서 코딩하는 5가지 방법

• Model은 Controller와 View에 의존하지 않아야 한다.
• View는 Model에만 의존해야 하고, Controller에는 의존하면 안 된다.
• View가 Model로부터 데이터를 받을 때는, 사용자 마다 다르게 보여주어야 하는 데이터에 대해서만 받아야 한다.
• Controller는 Model과 View에 의존해도 된다.
• View가 Model로부터 데이터를 받을 때, 반드시 Controller에서 받아야 한다.

 

 

 

우아한 테크 -MVC 패턴 리뷰- [레이어, MVC 패턴, 5 레이어]

[10분 테코톡] 🧀 제리의 MVC 패턴