MVC

• Model View Controller의 약자로 에플리케이션을 세가지의 역할로 구분한 개발 방법론이다.
  아래의 그림처럼 사용자가 Controller를 조작하면 Controller는 Model을 통해서 데이터를 가져오고 그 정보를 바탕으로 시각적인 표현을 담당하는 View를 제어해서 사용자에게 전달하게 된다.

1. 사용자가 웹사이트에 접속한다. (Uses)
2. Controller는 사용자가 요청한 웹페이지를 서비스 하기 위해서 모델을 호출한다. (Manipulates)
3. 모델은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후에 그 결과를 리턴한다.
4. Controller는 Model이 리턴한 결과를 View에 반영한다. (Updates)
5. 데이터가 반영된 VIew는 사용자에게 보여진다. (Sees)

Model

• 일반적으로 CI의 모델은 데이터베이스 테이블에 대응된다. 이를테면 Topic이라는 테이블은 topic_model이라는 Model을 만든다. 그런데 이 관계가 강제적이지 않기 때문에 규칙을 일관성 있게 정의하는 것이 필요하다.

View

• View는 클라이언트 측 기술인 html/css/javascript들을 모아둔 컨테이너이다.

Controller

• 사용자가 접근한 URL에 따라서 사용자의 요청사항을 파악한 후에 그 요청에 맞는 데이터를 Model에 의뢰하고, 데이터를 View에 반영해서 사용자에게 알려준다.

MVP

• Model, View, Presenter로 구성된 디자인 패턴이다.
• MVP의 핵심 설계는 MVC와 다르게 UI(View)와 로직(Model)을 분리하고, 서로 간에 상호작용을 다른 객체(Presenter)에 그 역할을 줌으로써, 서로의 영향(의존성)을 최소화하는 것에 있다.

특징

Model

• 프로그램 내부적으로 쓰이는 데이터를 저장하고, 처리하는 역할(비즈니스 로직)을 한다.
• View 또는 Presenter 등 다른 어떤 요소에도 의존적이지 않은 독립적인 영역이다.

View

• UI를 담당하며 안드로이드에서는 Activity, Fragment가 대표적인 예.
• Model에서 처리된 데이터를 Presenter를 통해 전달받아서 유저에게 보여준다.
• 유저의 행동(Action) 및 Activity 생명 주기 상태 변경을 주시하며 Presenter에 전달하는 역할이다.
• Presenter를 이용하여 데이터를 주고받기 때문에 Presenter에 매우 의존적이다.

Presenter

• Model과 View사이의 매개체다.
• Model과 View를 매개체라는 점에서 Controller와 유사하지만, View에 직접 연결되는 대신 인터페이스를 통해 상호작용한다는 차이가 있다.
• 인터페이스를 통해 상호작용하므로 MVC가 가진 테스트 문제와 함께 모듈화/유연성 문제 역시 해결할 수 있다.
• View에게 표시할 내용(Data)만 전달하며 어떻게 보여줄 지는 View가 담당한다.

MVP의 장점

• MVC와는 다르게 코드가 깔끔해지고, Model과 View의 결합도를 낮추면, 새로운 기능 추가 및 변경을 할때 마다 관련된 부분만 코드를 수정하면 되기 때문에 확장성이 개선된다.
• UI, Data 각각 파트를 나누어서 해야할 일(역할)이 명확해지고, 쉽고 빠른 코딩이 가능하다.

MVP의 단점

• 어플리케이션이 복잡해질수록 View와 Presenter 사이의 의존성이 강해지는 문제가 있다.
• MVC의 Controller처럼 추가 비즈니스 로직에 집중되는 경향이 있다.
• 개발자는 오랜 시간 앱을 개발하는 어느 순간, 거대해지며 문제가 발생하기 쉽고, 분리하기 어려운 Presenter를 발견하게 된다.
  • 초기에 설계/기획을 잘하면서 앱의 다양한 변화에 따라 대응한다면 위와 같은 문제는 발생하지 않지만, 쉽지 않다.

MVVM

• Model과 View는 MVC의 개념과 동일하다
• MVP와 마찬가지로 View와 Model을 분리시키기 위해 ViewModel이라는 개념이 들어온다
• View는 사용자 입력에 따른 자신이 이용할 ViewModel을 선택해 바인딩하여 업데이트를 받는다
• ViewModel과 Model이 상호작용을 하여 Model이 변경되면 ViewModel을 이용하는 View가 자동으로 업데이터 된다.
• 이로인해 View와 Model 사이의 의존성이 없고, MVP 처럼 View 와 ViewModel이 1:1 관계가 아닌 독립적이기 때문에 이 둘 사이의 의존성이 없다

특징

• Model
  • 데이터를 나타내는 역할, MVC와 동일하다
• View
  • 사용자에게 제공되는 UI
  • 사용자의 입력을 받고 이벤트를 자신이 사용할 ViewModel로 전달
• ViewModel
  • View를 나타내주기 위한 Model + View의 로직 담당
  • View와 독립적
  • UI 관련 데이터 보관 및 관리
  • Model이 변경되면 해당 ViewModel을 사용하는 View가 자동으로 업데이트

MVVM의 장점

• View에 대한 의존성이 전혀 없으므로 유닛 테스트에 용이
• 중복되는 코드를 모듈화 할 수 있음

MVVM의 단점

• ViewModel의 설계가 어렵다
• View에대한 처리가 복잡할수록 ViewModel이 거대해진다
• 상대적으로 View는 아무 역할도 하지 않음
• ViewModel이 또다른 형태의 액티비티 클래스 구현으로 변질될 우려가 있다

요약

• ViewModel의 initView() 부분을 보면 기존 액티비티에서 하던 일을 ViewModel이 하는것을 볼 수 있다.
• 이것이 MVVM 패턴이 액티비티의 LifeCycle의 영향을 받지 않고 ViewModel 인스턴스가 유지되면서 데이터를 안전히 다룰 수 있는 이유다.
• 그러나 앞서말했듯이 View가 할 일을 ViewModel이 대신 하기때문에 ViewModel에 로직들이 모이고 또다른 View 클래스를 생성한 꼴이 될 수 있으므로 유의하며 구현해야 한다.