MVC 패턴 vs MVVM 패턴

두 패턴 모두 소프트웨어 개발, 특히 UI(사용자 인터페이스)를 가진 애플리케이션 개발에서 코드를 구조화하고 관심사를 분리하기 위한 디자인 패턴입니다. 목표는 비슷하지만, 접근 방식과 각 구성 요소의 역할에서 차이가 있습니다.

1. MVC 패턴 (Model-View-Controller)

MVC는 UI를 가진 애플리케이션에서 가장 오래되고 널리 사용되는 패턴 중 하나입니다. 각 구성 요소가 명확한 역할을 가지고 있어, 코드를 체계적으로 관리하고 확장성을 높이는 데 도움을 줍니다.

• Model (모델):
  • 역할: 애플리케이션의 데이터와 비즈니스 로직을 담당합니다.
  • 특징:
    • 데이터를 표현(예: 데이터베이스에서 가져온 객체, 비즈니스 규칙을 포함한 클래스).
    • 데이터의 상태를 관리하고, 데이터를 조작하는 메서드를 포함합니다.
    • 뷰나 컨트롤러에 직접 의존하지 않습니다.
  • 예시: Product 클래스, UserService (사용자 데이터 처리 로직).
• View (뷰):
  • 역할: 사용자에게 데이터를 시각적으로 표시하는 부분입니다. (UI)
  • 특징:
    • 모델의 데이터를 받아 사용자에게 보여줍니다.
    • 사용자의 입력을 받아서 컨트롤러로 전달합니다.
    • 컨트롤러와 모델을 직접 알지 못하며, 단지 데이터를 표시하고 사용자 이벤트를 전달하는 역할만 합니다.
    • 수동적으로 모델의 변경 사항을 반영하거나, 컨트롤러를 통해 업데이트됩니다.
  • 예시: 웹 페이지(HTML/CSS), WPF/WinForms의 XAML/컨트롤.
• Controller (컨트롤러):
  • 역할: 모델과 뷰 사이의 중재자(Mediator) 역할을 하며, 사용자의 입력(이벤트)을 처리합니다.
  • 특징:
    • 뷰로부터 사용자 입력을 받습니다.
    • 이 입력을 해석하고, 필요한 경우 모델에게 데이터 변경을 요청합니다.
    • 모델에서 변경된 데이터를 받아 뷰를 업데이트하도록 지시합니다.
    • 자신은 데이터를 직접 처리하거나 UI를 직접 그리지 않습니다.
  • 예시: ASP.NET Core MVC의 HomeController, ProductController.

MVC의 흐름:

1. 사용자가 뷰에서 상호작용 (예: 버튼 클릭).
2. 뷰가 이 이벤트를 컨트롤러로 전달.
3. 컨트롤러는 이벤트에 따라 모델에게 데이터 처리 요청.
4. 모델이 데이터 처리 후, 상태가 변경되었음을 컨트롤러에 알림.
5. 컨트롤러는 변경된 모델 데이터를 뷰에 전달하여 뷰를 업데이트하도록 지시.

---

2. MVVM 패턴 (Model-View-ViewModel)

MVVM은 주로 데이터 바인딩(Data Binding) 기술이 풍부한 UI 프레임워크(예: WPF, UWP, Xamarin, Angular, Vue, React의 상태 관리)에서 강력한 장점을 가집니다. MVC의 파생형으로 볼 수도 있습니다.

• Model (모델):
  • 역할: MVC의 모델과 동일합니다. 애플리케이션의 데이터와 핵심 비즈니스 로직을 담당합니다.
  • 특징: UI와 독립적입니다.
• View (뷰):
  • 역할: 사용자에게 데이터를 시각적으로 표시하고, 사용자의 입력을 받습니다.
  • 특징:
    • MVC 뷰와 비슷하지만, ViewModel에 직접적으로 데이터 바인딩됩니다.
    • 사용자 입력(이벤트)을 직접 ViewModel의 명령(Command)에 바인딩하여 전달합니다.
    • UI 요소와 ViewModel 간의 양방향 데이터 바인딩이 핵심입니다.
    • 뷰는 ViewModel을 알지만, ViewModel은 뷰를 알지 못합니다.
  • 예시: WPF/Xamarin의 XAML, React/Angular/Vue의 컴포넌트 템플릿.
• ViewModel (뷰모델):
  • 역할: 뷰를 위한 모델이라고 생각할 수 있습니다. 뷰와 모델 사이의 중재자이자, 뷰의 상태와 뷰가 필요로 하는 데이터를 노출합니다.
  • 특징:
    • 데이터 바인딩: 뷰가 바인딩할 수 있는 속성(Properties)과 명령(Commands)을 노출합니다.
    • 모델과의 상호작용: 모델로부터 데이터를 가져오거나 모델에 데이터를 저장하도록 요청합니다.
    • 뷰 상태 관리: 뷰에 특화된 로직(예: UI 요소의 활성/비활성 상태, 메시지 표시 등)을 포함할 수 있습니다.
    • INotifyPropertyChanged: 속성이 변경될 때 뷰에 알림을 보내 뷰가 자동으로 업데이트되도록 합니다.
    • 뷰에 직접 의존하지 않으므로, 뷰모델은 쉽게 테스트할 수 있습니다.
  • 예시: ProductViewModel (뷰에 표시될 제품 정보와 관련된 메서드를 포함).

MVVM의 흐름:

1. 사용자가 뷰에서 상호작용 (예: 버튼 클릭).
2. 뷰의 UI 요소가 ViewModel의 Command에 바인딩되어, 명령 실행.
3. ViewModel은 명령에 따라 모델에게 데이터 처리 요청.
4. 모델이 데이터 처리 후, ViewModel에 결과 전달.
5. ViewModel의 속성(Properties)이 업데이트되고, INotifyPropertyChanged를 통해 뷰에 알림.
6. 뷰는 데이터 바인딩에 따라 자동으로 업데이트.

---

간략한 차이점 요약

특징	MVC (Model-View-Controller)	MVVM (Model-View-ViewModel)
중재자	Controller (뷰와 모델 사이에서 사용자 입력 처리 및 뷰 업데이트 지시)	ViewModel (뷰를 위한 모델 역할, 뷰와 모델 간의 데이터 및 명령 바인딩)
뷰와 모델 관계	컨트롤러를 통해 간접적으로 상호작용 (컨트롤러가 뷰를 업데이트)	ViewModel을 통해 데이터 바인딩으로 직접 상호작용 (뷰가 ViewModel 속성에 바인딩)
테스트 용이성	컨트롤러 로직은 테스트하기 쉽지만, 뷰 로직은 어려울 수 있음	ViewModel이 뷰 로직의 상당 부분을 캡슐화하여 뷰모델 테스트 용이
UI 기술과의 관계	특정 UI 기술에 덜 의존적 (웹, 데스크톱 모두 널리 사용)	데이터 바인딩이 강력한 UI 프레임워크(WPF, Angular, React, Vue)에 특히 적합
핵심 기술	요청-응답 주기, 이벤트 핸들링	데이터 바인딩, Command, INotifyPropertyChanged

간단히 말해, MVC는 컨트롤러가 뷰를 "수동으로" 업데이트하는 방식이고, MVVM은 뷰모델과 뷰가 "자동으로" 데이터 바인딩되는 방식이라고 생각할 수 있습니다. MVVM은 특히 UI와 데이터의 긴밀한 동기화가 필요한 복잡한 클라이언트 애플리케이션에서 더 강력한 장점을 발휘합니다.