MVC 패턴이란?

[ 목차 ]

MVC 패턴이란?

- MVC 패턴은 Model, View, Controller의 약자로, 애플리케이션을 세 가지 주요 구성 요소로 나눠서 구조화하는 디자인 패턴이다. 각 구성 요소의 역할이 명확하게 분리되어 있어 코드의 유지보수성과 확장성이 높아진다.

Model (모델)

Model은 소프트웨어나 애플리케이션의 정보 및 데이터 관리를 담당하는 부분을 의미한다. 모델은 비즈니스 로직을 포함하고, 데이터베이스와의 상호작용을 통해 데이터를 처리하고 저장한다. 또한, 모델은 뷰나 컨트롤러와 독립적으로 존재하여 데이터와 관련된 작업을 수행하는 객체라고 보면 된다.

 

Model이 가지는 규칙은 다음과 같다.

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

 

View (뷰)

View는 입력값이나 체크박스 등과 같은 사용자 인터페이스 요소를 나타낸다. 이는 Controller에게 받은 Model의 데이터를 사용자에게 시각적으로 보여주기 위한 역할을 한다. 컨트롤러로부터 전달받은 모델의 데이터를 기반으로 화면을 렌더링합니다. 사용자와 상호작용하며, 그 상호작용에 따라 컨트롤러에 알림을 전달다.

View가 가지는 규칙은 다음과 같다.

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

 

Controller (컨트롤러)

Controller는 사용자 요청을 처리하고, Model과 View를 연결하는 중개자 역할을 한다. 사용자의 입력을 받아 모델에 필요한 작업을 요청하고, 모델이 반환한 데이터를 뷰로 전달한다. 컨트롤러는 비즈니스 로직을 직접 다루지 않고, 필요한 경우 모델이나 서비스 계층에 해당 작업을 위임합니다. 이는 MVC 패턴에서 각 컴포넌트가 독립적으로 관리될 수 있도록 하기 위함입니다.  결국 Controller는 Model과 View의 역할을 분리하는 중요한 요소이다.

Controller가 가지는 규칙은 다음과 같다.

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

 

MVC패턴의 동작 흐름

1. 사용자의 요청(Request):
   • 사용자가 브라우저나 UI에서 특정 액션을 수행하면(예: 버튼 클릭, URL 요청) 해당 요청이 Controller로 전달된다.
2. Controller의 요청 처리:
   • 컨트롤러는 사용자 요청을 해석하고, 어떤 작업을 수행할지 결정한다.
   • 이때, 컨트롤러는 비즈니스 로직이 아닌 요청과 모델 간의 중개 역할만 수행한다.
   • 사용자의 요청이 데이터를 필요로 하면 모델에 접근하여 데이터를 가져오거나 수정하는 작업을 한다.
3. 모델(Model)의 데이터 처리:
   • 모델은 컨트롤러로부터 요청받은 데이터를 처리하고, 비즈니스 로직에 따라 데이터를 조작한다. 예를 들어, 데이터베이스에 정보를 저장하거나 가져오는 작업을 수행할 수 있다.
   • 모델은 애플리케이션의 상태와 관련된 정보를 관리하며, 요청에 따른 데이터를 반환한다.
4. 컨트롤러(Controller)의 데이터 전달:
   • 모델이 처리한 데이터를 다시 컨트롤러로 전달한다.
   • 컨트롤러는 이 데이터를 바탕으로 사용자에게 어떻게 보여줄지 결정하고, 뷰를 선택하여 데이터를 전달한다.
5. 뷰(View)의 데이터 렌더링:
   • 뷰는 컨트롤러로부터 받은 데이터를 사용자가 볼 수 있는 형태로 렌더링한다.
   • 이 과정에서 HTML, CSS, JavaScript를 사용해 웹 페이지를 구성하거나, JavaFX, Swing 같은 GUI 라이브러리를 통해 UI를 구성할 수 있다.
   • 렌더링된 결과는 최종적으로 사용자에게 보여진다.

 

 

MVC 패턴의 장단점

장점

1. 코드의 모듈화와 책임 분리:
   • MVC는 애플리케이션을 세 가지 역할로 분리하여, 각 컴포넌트가 독립적으로 동작하도록 한다. 이를 통해 코드의 가독성과 유지보수성이 크게 향상된다.
   • 예를 들어, 데이터와 관련된 로직이 모델에 집중되어 있어 뷰와 컨트롤러는 데이터에 직접 접근하지 않기 때문에, 데이터가 변경되더라도 컨트롤러나 뷰 코드를 수정할 필요가 없다.
2. 개발과 유지보수의 용이성:
   • 프로젝트가 커지더라도 각 역할이 분리되어 있어, 특정 역할을 변경할 때 다른 부분에 영향을 주지 않도록 할 수 있다.
   • 특히 대규모 팀 프로젝트에서 팀원들이 뷰, 모델, 컨트롤러 각 부분을 병렬적 개발이 가능해, 개발 속도를 높일 수 있다.
3. 재사용성과 테스트 용이성:
   • MVC는 모델, 뷰, 컨트롤러를 독립적으로 테스트할 수 있어, 유닛 테스트나 통합 테스트 작성이 용이하다.
   • 또한, 동일한 모델을 다른 뷰에서 재사용할 수 있어, 뷰를 수정하거나 여러 뷰를 지원하는 경우에도 기존 모델을 재사용할 수 있다.
4. 유연성과 확장성:
   • MVC 패턴을 사용하면 새로운 기능 추가나 UI 변경이 필요한 경우, 기존 코드를 최소한으로 수정하면서 추가할 수 있다.

 

단점

1. 복잡도 증가:
   • MVC 패턴을 도입할 때 애플리케이션 구조가 복잡해질 수 있다. 특히 작은 프로젝트에서는 오히려 과도한 분리가 되어 개발 속도가 느려질 수 있다.
   • 또한 각 컴포넌트 간의 상호작용이 많아지면, 코드의 흐름을 추적하는 것이 어려울 수 있다.
2. 의존성 증가:
   • 컨트롤러는 모델과 뷰에 의존성을 가지며, 이로 인해 컨트롤러가 비대해질 가능성이 있다.
   • 대규모 프로젝트에서는 각각의 의존성을 관리하고, 각 부분의 결합도를 낮추기 위한 추가적인 작업이 필요하다.
3. 이벤트 흐름의 복잡성:
   • 사용자가 보는 뷰에서 발생하는 이벤트가 모델과 컨트롤러를 거치며 순차적으로 전달되기 때문에, 이벤트가 많은 애플리케이션에서는 코드의 흐름을 이해하기 어려워질 수 있다.
   • 이로 인해, 디버깅과 유지보수가 어려워질 가능성이 있다.
4. 기본 설정 및 구조화 작업:
   • MVC 패턴을 사용하기 위해 프로젝트 초기에 기본적인 설정과 구조화 작업이 필요하다.
   • 그래서 초기 개발 속도가 느려질 수 있고, 프로젝트의 규모나 특성에 따라 필요한 기본 작업량이 많아질 수 있다.

 

 

 

- MVC 패턴은 내가 작성한 것 외에도 많은 장점이 있다. 물론 규모가 작은 프로젝트에서는 단점이 더 크게 느껴질수는 있지만 규모가 큰 프로젝트나 복잡한 비즈니스 로직을 가진 애플리케이션에서는 단점보다 장점이 압도적이기 때문에,

많고 다양한 환경에서 선호하는 것 같다!

 

 

출처

https://velog.io/@langoustine/%EC%97%AC%EA%B8%B0%EB%8F%84-MVC-%EC%A0%80%EA%B8%B0%EB%8F%84-MVC-MVC-%ED%8C%A8%ED%84%B4%EC%9D%B4-%EB%AD%90%EC%95%BC

여기도 MVC, 저기도 MVC! MVC 패턴이 뭐야?

https://m.blog.naver.com/jhc9639/220967034588

[개발자 면접준비]#1. MVC패턴이란