아키텍처 패턴

프로그램의 Presentation Logic과 Business Logic들을 구현함에 있어서 데이터와 UI는 필수이기 때문에 Model(데이터 or 데이터를 생성하거나 업데이트) - View(UI or 화면을 표시) 사이의 의존성이 당연히 생길 수 밖에 없습니다.

• Presentation Logic: 실제 눈에 보이는 GUI(Graphic User Interface) 화면을 구성하는 코드를 뜻함

• Business Logic: 데이터를 보여주기 위해서 데이터베이스를 검색하는 코드 및 GUI 화면에서 새롭게 발생된 데이터를 데이터베이스에 저장하는 코드 등 실제적인 작업을 하는 코드를 뜻함

이러한 Logic들이 커지고 복잡해짐에 따라 의존성은 더 강해지고, 결국 앱을 유지보수하기가 점점 어려워집니다. 이러한 문제를 해결하기 위해서 여러 패턴들이 나왔고 각각의 역할을 나눠서 코드를 관리하게 되었습니다. 역할을 나눠서 관리하면 유지보수와 개발효율이 좋아지는 것입니다.

아키텍처 패턴의 종류

MVC(Model-View-Controller)

프로그램을 각각의 역할에 따라 Model, View, Controller로 나누어 설계한 아키텍처 패턴

• Model: 애플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분
• View: 사용자에게 보여지는 UI 부분
• Controller: 사용자의 입력(Action)을 받고 처리하는 부분

동작

1. 사용자의 입력들은 Controller로 전달됩니다.
2. Controller는 입력을 확인하고 Model을 업데이트합니다.
3. Controller는 업데이트 된 결과(Model)를 나타내 줄 View를 선택합니다.
   (하나의 Controller는 View를 선택할 수 있기 때문에 1:n 관계로, 여러 개의 View를 관리할 수 있습니다)
4. Controller는 View를 선택만 할 뿐, 직접 업데이트하지 않습니다.
   (View는 Controller를 알지 못합니다.)
5. View를 업데이트하기 위해서는 아래와 같은 방법을 이용합니다.
   5.1 View가 Model을 직접 이용하여 업데이트
   5.2 Model에서 View에게 Notify하여 업데이트
   5.3 View가 Polling하여 Model의 변화를 감지해서 업데이트

장점

• 가장 단순한 패턴입니다.

단점

• Model과 View 사이의 의존성이 발생합니다. 따라서 앱이 커지고 복잡해질수록 유지보수가 어려워집니다.
• 게다가 안드로이드는 Activity(또는 Fragment)가 Controller와 View를 모두 처리하기에 한 클래스에서 M-V-C 모두 처리하게 되는 문제점이 발생합니다.

MVP(Model-View-Presenter)

MVC에서 파생된, Model과 View간의 의존성이 없는 아키텍처 패턴

• Model: 애플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분
• View: 사용자에게 보여지는 UI 부분
• Presenter: View에서 요청한 정보로 Model을 가공해 View에게 전달해 주는 부분

동작

1. 사용자의 입력들은 View로 전달됩니다.
2. View는 데이터를 Presenter에게 요청합니다.
3. Presenter는 Model에게 데이터를 요청합니다.
4. Model은 Presenter에서 요청받은 데이터를 응답합니다.
5. Presenter는 View에게 데이터를 응답합니다.
6. View는 Presenter가 응답한 데이터를 이용하여 화면을 나타냅니다.

특징

• Presenter는 View와 Model 인스턴스를 가지고 그 둘 사이의 매개체 역할을 합니다.
  (View와 Presenter는 1:1 관계)

장점

• Model과 View사이의 의존성이 없습니다.

단점

• View와 presenter가 1:1 관계이기 때문에 서로 간 의존성이 커집니다. 즉, 앱이 커지거나 복잡해질 수록 View-Presenter 간의 의존성이 강해지는 문제점이 발생합니다.
• 필요한 클래스의 개수가 많습니다.

MVVM(Model-View-ViewModel)

MVC에서 파생된, Model과 View 간의 의존성뿐만 아니라 Controller와 View 간의 의존성도 고려하고 각 구성 요소가 독립적으로 작성되고 테스트될 수 있도록 설계된 아키텍처 패턴

• Model: 애플리케이션에서 사용되는 데이터와 그 데이터를 처리하는 부분
• View: 사용자에게 보여지는 UI 부분
• ViewModel: View를 표현하기 위해 만들어진 View를 위한 Model

동작

1. 사용자의 입력들은 View를 통해 들어오게 됩니다.
2. View에 Action이 들어오면, Command 패턴으로 View Model에 Action을 전달합니다.
3. View Model은 Model에게 데이터를 요청합니다.
4. Model은 View Model에게 요청받은 데이터를 응답합니다.
5. View Model은 응답 받은 데이터를 가공하여 저장합니다.
6. View는 View Model과 Data Binding하여 화면을 나타냅니다.

특징

• MVVM 패턴은 Command 패턴과 Data Binding 두 가지 패턴을 사용하여 구현되었습니다.
• Command 패턴과 Data Binding을 이용해 View와 View Model 사이의 의존성을 없앴습니다.
• View Model과 View는 1:N 관계입니다.

장점

• Model과 View 사이의 의존성이 없습니다.
• View Model과 View 사이의 의존성이 없습니다.
• 중복되는 코드를 모듈화할 수 있습니다.

단점

• View Model은 설계가 쉽지 않습니다.

MVC, MVP, MVVM 읽고 글 수정한 후 MVVM에 대한 간단한 예제 올리기

참조
MVC, MVP, MVVM 패턴의 구조
MVc, MVP, MVVM, MVI
Android Architecture Patterns Part 1: Model-View-Controller(MVC)
Android Architecture Patterns Part 2: Mocel-View-Presenter(MVP)
Android Architecture Patterns Part 3: Model-View-ViewModel(MVVM)

틀린 부분을 댓글로 남겨주시면 수정하겠습니다..!!