MVC 패턴이 무엇일까?

 

 

 

MVC (Model-View-Controller) 

소프트웨어 설계 패턴 중 하나로 주로 웹 애플리케이션에서 많이 사용된다.

이 패턴은 애플리케이션의 구조를 세 가지 역할로 분리하여 유지보수성과 확장성을 높여준다.

각 요소는 서로 독립적이지만 협력하여 사용자와의 상호작용을 처리한다.

 

 

 

 

 

 

MVC의 구성 요소

1. Model (모델)
2. View (뷰)
3. Controller (컨트롤러)

 

 

 

 

 

 

 

Model (모델)

데이터와 비즈니스 로직을 담당하는 부분이다.

데이터는 데이터베이스에 있는 데이터일 수도 있고, 애플리케이션 내에서 사용되는 비즈니스 상태 정보일 수도 있다.

 

역할

모델은 애플리케이션의 핵심 데이터를 관리하며 데이터의 저장, 수정, 삭제와 같은 작업을 처리한다.

또한 데이터를 다른 컴포넌트(주로 뷰)로 전달한다.

 

예시

쇼필몰 애플리케이션에서 상품 정보, 재고 수량, 사용자 정보 등을 처리하는 것이 모델의 역할

 

 

 

 

 

 

 

 

 

View (뷰)

View는 사용자 인터페이스(UI) 부분을 담당한다.

사용자에게 데이터를 시각적으로 보여주고, 사용자가 애플리케이션과 상호작용할 수 있도록 한다.

 

역할

모델로부터 받은 데이터를 기반으로 화면을 렌더링하며 사용자가 보는 페이지나 화면을 구성한다.

뷰는 데이터가 어떻게 표시될지에 대한 부분만 처리하고, 비즈니스 로직에는 관여하지 않는다.

 

예시

쇼핑몰 애플리케이션에서 상품 목록을 보여주는 웹 페이지, 상품 상세 페이지, 주문 내역 페이지 등이 뷰에 해당한다.

 

 

 

 

 

 

 

 

 

Controller (컨트롤러)

Controller는 사용자의 입력을 처리하고 그 입력을 모델과 뷰로 전달하는 역할을 한다.

즉, 사용자의 요청에 따라 비즈니스 로직을 수행하고 그 결과를 뷰에 전달한다.

 

역할

사용자가 뷰를 통해 요청한 데이터를 모델에게 전달하고, 모델이 처리한 데이터를 다시 뷰로 전달하는 중간 역할을 한다.

사용자의 액션(클릭, 요청 등)에 따라 적절한 응답을 수행한다.

 

예시

쇼핑몰에서 사용자가 '장바구니에 상품 추가' 버튼을 클릭하면 그 클릭 이벤트를 처리하고 해당 상품을 장바구니에 추가하는 로직을 수행하는 것이 컨트롤러의 역할이다.

 

 

 

 

 

 

 

MVC 패턴의 동작 방식

1. 사용자가 뷰와 상호작용한다.
   사용자가 웹 브라우저나 앱 화면에서 버튼을 클릭하거나, 데이터를 입력하거나, 특정 페이지로 이동하는 동작을 한다.
2. 컨트롤러가 사용자의 요청을 처리한다.
   사용자의 입력이나 요청이 컨트롤러로 전달된다.
   컨트롤러는 이 입력을 기반으로 어떤 작업이 필요한지를 결정한다.
3. 모델이 데이터를 처리한다.
   컨트롤러가 모델에게 필요한 데이터를 요청하거나 데이터를 수정한다.
   모델은 데이터베이스나 비즈니스 로직을 통해 요청된 데이터를 처리하고 그 결과를 컨트롤러에 반환한다.
4. 뷰가 데이터를 표시한다.
   컨트롤러는 모델로부터 받은 데이터를 뷰로 전달하고, 뷰는 이 데이터를 사용자에게 표시할 UI로 렌더링한다.

 

 

 

 

 

 

 

MVC 패턴의 장점

• 유지보수성과 확장성
  각각의 요소가 독립적으로 동작하기 때문에 한 부분을 수정하더라도 다른 부분에 큰 영향을 미치지 않는다.
  예를 들어 UI 디자인을 수정할 때도 비즈니스 로직에는 영향을 미치지 않으므로 수정이 용이하다.
• 역할 분리
  모델, 뷰, 컨트롤러가 각각의 역할에 집중하기 때문에 코드가 명확하게 나뉜다.
  코드의 가독성을 높이고 팀 단위의 협업에서도 효율성을 증대시킨다.
• 테스트 용이성
  모델과 비즈니스 로직이 뷰와 분리되어 있기 때문에 모델과 컨트롤러 부분을 독립적으로 테스트할 수 있다.
  특히 테스트 주도 개발(TDD)에 유리하다.
• 재사용성
  뷰와 모델이 분리되어 있기 때문에 하나의 모델을 여러 뷰에서 사용할 수 있다.
  예를 들어 같은 데이터를 웹, 모바일, 데스트탑 환경에서 각각의 UI로 표시할 수 있다.

 

 

MVC 패턴의 단점

• 초기 설계의 복잡성
  MVC 패턴을 처음 적용할 때는 세 가지 역할을 나누는 설계가 복잡할 수 있다.
  특히 작은 프로젝트에는 MVC를 적용하는 것이 오히려 과도할 수 있다.
• 복잡한 데이터 흐름
  사용자 요청이 컨트롤러를 거쳐 모델로 갔다가 다시 컨트롤러를 통해 뷰로 가는 과정은 직관적이지 않을 수 있으며 설계가 잘못되면 데이터 흐름이 복잡해질 수 있다.

 

 

 

 

 

 

 

왜 Model, View, Controller 로 나누었을까?

 

- 사용자의 요구사항을 가장 효율적으로 처리하기 위해

- 소프트웨어의 구조를 단순하고 명확하게 유지하기 위해

- 각각의 역할에 가장 적합한 형태로 책임을 분리할 수 있기 때문에

 

• 책임 분리의 이상적인 형태
  MVC는 각 부분이 명확한 책임을 가지고 있다는 점에서 이상적이다.
  Model은 데이터 관리, View는 UI처리, Controller는 로직 흐름 제어 라는 각각의 역할에 집중할 수 있기 때문에, 변경의 영향 범위를 최소화할 수 있다. 
  즉, UI가 바뀌어도 Model에는 영향을 주지 않고, 데이터 처리 로직이 바뀌어도 View나 Controller 에는 영향을 주지 않는다.
  
  
• 재사용성과 유연성
  MVC 구조는 각 부분이 독립적으로 동작하므로 재사용성이 높다.
  Model은 웹 앱이나 모바일 앱에서 동일하게 사용할 수 있고, 다양한 View에서 같은 Model을 이용할 수 있다.
  UI나 데이터 처리 로직을 독립적으로 바꿀 수 있으므로 변경이 빈번한 프로젝트에서 유연성을 크게 제공한다.
  
  
• 확장성과 유지보수성
  MVC 패턴은 대규모 프로젝트에서도 확장성을 제공한다. 새로운 기능을 추가할 때, 특정 역할만 확장하거나 변경하면 되기 때문에 시스템의 복잡성이 증가해도 유지보수가 용이하다.

 

 

 

 

 

 

 

MVC 패턴의 변형

MVC 패턴의 변형으로느 MVVM(Model-View-ViewModel), MVP(Model-View-Presenter) 등이 있다.

이 변형들은 주로 UI의 복잡성이나 데이터 흐름의 요구사항에 따라 특정 부분을 더 명확하게 분리하느 구조로 발전된 설계 패턴들이다.