MVC, MVP, MVVM

MVC(Model, View, Cotroller)

---

MVC에선 소프트웨어를 세 가지 역할로 구분한다.

1. Model
   -소프트웨어가 "무엇"을 할 것인지 정의한다.
   -비즈니스 로직, 소프트웨어에서 데이터를 처리하는 역할을 한다.
   -사용자에게 필요한 모든 데이터를 가지고 있어야 한다.
   비즈니스 로직 : 업무에 필요한 데이터를 처리하는 응용프로그램의 일부
   
2. Controller
   -Model과 View사이에서 통신을 담당한다.
   -View를 선택하여 사용자로부터 데이터를 입력받으면 이를 Model에 전달한다.
   
   
3. View
   -User Interface로서, 실제로 사용자에게 보여지는 역할을 한다.
   -Model이 처리한 데이터를 넘겨받아 이를 가지고 화면을 만든다.
   -Model을 통해 업데이트 하기 때문에 의존도가 높다.

안드로이드에서는 View와 Controller를 나눌 수 없어 둘이 하는 일을 Activity또는 Fragment에서 수행한다.

 

MVC의 장점
MVC는 비즈니스 로직과 UI요소들을 분리시키기 때문에 다음과 같은 장점이 있다.

• 디자이너와 개발자의 협업이 용이하다.
• 유연하고 확장이 쉽다.
• 유지보수가 용이하다.

MVC의 단점

• Model과 View의 완벽한 분리가 어렵고 결합도가 높다.
• 설계 단계에서 클래스가 많아져 구조가 복잡해질 수 있다.
• 유닛 테스트가 어렵다.

유닛 테스트 : 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차다.

 

MVP(Model, View, Presenter)

---

MVP도 마찬가지로 세 가지 역할로 구분된다.

1. Model
   -MVC와 동일하게 비즈니스 로직 역할을 한다.
   
   
2. Presenter
   -View와 Model을 연결하는 매개채가 된다.
   -MVC의 Controller와 같은 역할을 하지만, View에 연결되지 않고 Interface로 연결된다.
   
   
3. View
   -MVC와 마찬가지로 UI역할을 한다.
   -데이터 처리 시 Presenter를 호출하고, Presenter가 Model과 통신한다.
   -MVC와 달리 Model에 의존적이지 않다.
   -Presenter에 대한 의존성이 매우 높다.

MVP의 장점

• View와 Model사이에 의존성이 없다.
• 기능 추가 및 변경 시 해당 부분만 수정하면 되기 떄문에 확장성이 좋다.
• 유닛 테스트 시 테스트코드 작성이 편리하다.

MVP의 단점

• View와 Presenter사이에 의존성이 강하다.
• MVC의 Controller처럼 Presenter가 거대해지고, 복잡해져서 다루기 어려울 수 있다.
• View와 Presenter의 관계가 1:1이어야 하기 때문에 1개의 View당 1개의 Presenter가 필요하다.

MVVM(Model, View, ViewModel)

---

MVVM은 Controller나 Presenter대신 ViewModel이라는 것이 추가되었다.

1. Model
   -MVC, MVP와 마찬가지로 비즈니스 로직 역할을 한다.
2. ViewModel
   -View가 사용할 메서드와 필드를 구현한다.
   -ViewModel과 View는 1:n관계를 형성한다.
   -Model에게 필요한 데이터를 요청한다.
3. View
   -마찬가지로 UI역할을 수행한다.
   -View는 ViewModel객체를 관찰(Observing)하여 관찰 필드에 변화가 생기면
    즉시 알람을 받고, 알맞은 View렌더링 로직을 수행한다.(data binding)

MVVM의 장점

• View에 대한 ViewModel이나 Model의 의존도가 전혀 없기 때문에 유닛 테스트가 용이하다.
• View와 ViewModel의 data binding을 통해 코드의 양이 줄어든다.
• 개발자와 디자이너가 독립적으로 일을 수행할 수 있기 때문에 협업이 편하다.

MVVM의 단점

• 대형 앱에서 사용하기 위해 고안된 패턴이기 때문에 소형 앱에서 사용할 경우 오버헤드가 크다.
• data binding이 필수적이며, 앱이 너무 거대해질 경우
  MVC나 MVP처럼 ViewModel이 비대해지고, 메모리 소모가 커진다.