MVC, MVP, MVVM 패턴

 

MVC 패턴

애플리케이션의 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만 집중해서 개발할 수 있도록 하는 소프트웨어 아키텍쳐 패턴입니다. 관심사를 모델, 뷰, 컨트롤러라는 세가지 구성 요소로 분리하는 것을 목적으로 합니다.

 

• 모델(Model): 모델은 애플리케이션의 데이터와 비즈니스 로직을 나타냅니다. 데이터를 캡슐화하고 조작하며, 데이터에 액세스하기 위한 메서드를 제공합니다. 뷰에서 데이터를 생성하거나 수정하면 컨트롤러를 통해 모델을 생성하거나 갱신합니다. 클라이언트 측 데이터 조작이나 유효성 검사도 포함될 수 있습니다.

 

• 뷰(View): 뷰는 응용 프로그램에서 표현 계증을 담당하고, 데이터를 어떻게 사용자에게 표시할지 정의합니다. 이때 모델이 가지고 있는 정보를 따로 저장하지 않아야 합니다. 뷰는 모델이나 사용자 상호 작용의 변경에 따라 사용자 인터페이스를 렌더링하고 업데이트하는 역할을 합니다. 뷰는 재사용이 가능하고 데이터 소스와 독립적으로 설계되어야합니다. 

 

• 컨트롤러(Controller): 컨트롤러는 모델과 뷰 사이의 중재자(다리) 역할을 합니다. 사용자로부터의 입력을 받아 처리하고, 이에 따라 모델이나 뷰를 업데이트합니다. 모델과 뷰의 생명주기도 관리하며, 모델이나 뷰의 변경 통지를 받으면 이를 해석하여 각각의 구성 요소에 해당 내용에 대해 알려줍니다. 

---

MVC 패턴의 예

리액트

 

1. 모델 : 리액트에서 모델은 애플리케이션의 데이터와 상태를 나타내는데, 데이터를 관리하고 저장하는 컴포넌트로 구성됩니다. 리액트에서 상태는 일반적으로 개별 컴포넌트 내에서 관리되거나 여러 컴포넌트간에 공유하기 위해 상위 수준 컴포넌트로 끌어올려집니다. 

 

2. 뷰 : 사용자 인터페이스 컴포넌트를 의미하는데, 리액트에서는 JSX를 사용하여 UI의 구조와 레이아웃을 정의합니다. 리액트에서 컴포넌트는 현재 상태와 부모 컴포넌트에서 전달된 프롭스에 따라 UI를 렌더링하는 로직을 캡슐화합니다.

 

3. 컨트롤러 :  리액트에서 컨트롤러는 사용자 상호 작용을 처리하고 모델의 변경을 트리거하는 컴포넌트로 생각할 수 있습니다. 하지만 리액트는 따로 특정 컨트롤러 컴포넌트를 갖고 있지 않습니다. 대신 리액트는 이벤트 핸들러와 콜백을 사용하여 컴포넌트 내에서 사용자 동작이나 외부 이벤트에 응답을 하고, 이벤트 핸들러는 컴포넌트의 상태를 수정하거나 상위 수준 컴포넌트의 상태를 업데이트하는 함수를 호출할 수 있습니다. 

 

리액트 MVC 패턴의 흐름 요약

1. 사용자가 UI와 상호 작용합니다. 예를 들면 버튼 클릭하거나 입력을 입력합니다. 
2. 리액트 컴포넌트와 연결된 이벤트 핸들러가 사용자의 상호 작용을 캡처합니다. 
3. 이벤트 핸들러가 컴포넌트의 상태를 수정하거나 부모 컴포넌트로 전달된 프롭스를 업데이트하는 함수를 호출합니다. 
4. 상태 변경에 따라 자식 컴포넌트들을 다시 렌더링합니다. 
5. UI 컴포넌트는 업데이트 된 프롭스를 받아들이고 UI를 그에 따라 렌더링합니다. 
6. 업데이트된 UI가 사용자에게 표시되어, 사용자의 상호 작용에 대한 변경 사항을 반영합니다. 

 

---

MVP 패턴

MVC 패턴에서 파생되어 컨트롤러가 프레젠터로 교체된 패턴입니다.

 

그런데 MVC와의 차이점은 뭘까요?

 

일단 컨트롤러와 프레젠터는 뷰와 모델 사이의 중재작 역할을 하는 것은 같습니다. 하지만 MVC에서는 뷰와 모델이 컨트롤러에 의존할 수 있지만, MVP에서는 뷰가 수동적이며 프레젠터에 대한 참조가 있지만 직접적인 의존성은 없습니다. 그리고 MVP는 뷰와 모델을 모킹하거나 스텁화하여 유닛테스트를 쉽게 할 수 있습니다. 

 

---

MVVM 패턴 

MVVM 패턴은 MVC패턴에 컨트롤러가 뷰모델로 바뀐 패턴입니다. 뷰모델은 뷰를 더 추상화한 계층이고 커맨드와 데이터 바인딩을 가지는 것이 특징입니다. 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원하며 UI를 별도 코드 수정없이 재사용할 수 있고, 단위 테스팅이 쉽다고 합니다. 예로 들면 Vue 프레임워크가 있습니다. watch와 computed등을 통해서 함수를 사용하지 않고 값 대입만으로도 변수가 변경되어 재사용 가능한 컴포넌트 기반으로 UI 구축이 가능합니다. 

 

---

 

	Pros	Cons
MVC	1. 관심사 분리을 분리하여  모듈화되고 유지 관리하기 쉽게 만듭니다. 2. 애플리케이션의 여러 부분에서 모델과 뷰를 재사용할 수 있습니다. 3. MVC는 잘 알려져 있고 널리 채택된 패턴	1. 대규모 애플리케이션에서 MVC는 복잡해질 수 있다. 2. 뷰와 컨트롤러 간의 양방향 종속성은 단위 테스트를 어렵게 만들 수 있습니다. 3. 뷰 업데이트를 위한 명확한 메커니즘을 제공하지 않으므로 모델과 뷰를 수동으로 동기화해야 합니다.
MVP	1. 애플리케이션 로직을 뷰에서 분리하므로 뷰와 모델을 모킹하거나 스텁핑하여 단위 테스트를 더 쉽게 수행할 수 있습니다. 2. 뷰는 수동적이며 프레젠터에 대한 참조가 있으므로 종속성이 줄어들고 유지 관리가 용이 3. 프레젠터에 영향을 주지 않고 뷰 또는 모델을 쉽게 교체하거나 수정할 수 있으므로 다양한 UI 구현에 적합합니다.	1. 추가 레이어(프레젠터)를 도입하므로 MVC에 비해 코드베이스의 복잡성이 증가할 수 있습니다. 2. 이 패턴에 익숙하지 않은 개발자에게는 학습 곡선이 필요할 수 있습니다. 3. 뷰와 프레젠터가 모두 UI 관련 작업을 처리하기 때문에 뷰와 프레젠터 간에 코드가 중복될 수 있습니다.
MVVM	1. 데이터(모델), UI 렌더링(뷰), 뷰의 상태를 조작하는 로직(뷰모델)을 관심사로 분리하여 더 깔끔하고 유지 관리하기 쉬운 코드를 생성 2. 강력한 데이터 바인딩 기능을 제공하여 모델, 뷰, 뷰모델 간의 자동 동기화를 지원합니다. 3. 뷰의 상태 조작 로직이 뷰모델에서 분리되어 있어 실제 뷰 없이도 단위 테스트를 쉽게 수행할 수 있습니다.	1.  패턴이나 프레임워크를 처음 접하는 개발자의 경우 학습 곡선이 가파를 수 있습니다. 2. 데이터 바인딩을 활성화하기 위해 특정 프레임워크 또는 라이브러리에 의존하는 경우가 많으며, 이로 인해 종속성이 발생하고 유연성이 제한될 수 있습니다.