1. MVC (Model, View, Controller)
Model
앱에서 사용하는 데이터, 상태, 비즈니스 로직을 포함한다.
- 데이터 : 사용자의 이름이나 상품의 가격 등과 같은 말 그대로의 데이터를 의미.
- 상태 : UI 상태. isEnabled와 같은 플래그로 UI의 상태를 나타낼 수도 있고, 데이터의 값이 변경되어 UI가 갱신되어야 한다면 그 또한 상태 변경으로 볼 수 있다.
- 비즈니스 로직 : 앱에 필요한 동작을 수행하기 위해서 데이터를 처리하기 위한 알고리즘.
View
사용자가 보는 화면, 즉 UI요소를 담당한다..
사용자의 입력에 대해 어떤 동작을 해야하는지는 모른다. 예를 들어 UI에 있는 버튼을 눌렀을 때 처리해야하는 코드를 포함하지 않는다. 안드로이드에서 레이아웃 파일인 activity_main.xml과 같은 형태이기 때문에 어떤 동작을 처리하기 위한 코드를 담기에는 어렵다. 단순히 화면을 보여주는 역할을 한다.
Controller
Model과 View의 가교역할. View가 사용자에게 입력을 받으면 이를 Controller에게 알린다.
Controller는 적절한 조치를 취하기 위한 동작을 한다. 예를 들어 Model과 상호작용하여 UI 상태를 갱신할 수 있다.
안드로이드에서 이러한 역할을 하는 것은 Activity 혹은 Fragment이다.
Activity와 Fragment를 보면, View와 실제로 연결되고, 사용자에게 어떠한 입력을 받았을 때 처리할 동작을 구현할 수 있다. 이때 Model 인스턴스를 생성하여 필요한 비즈니스 로직을 요청하고 결과 데이터를 가져오면 View와 연결되어 있기 때문에 UI 갱신까지 Controller에서 가능하다. 그렇기 때문에 Controller는 Model과 View를 연결하는 가교 역할을 한다.
MVC 정리
View와 Model은 서로 분리되어 있다. 그리고 Model은 종속되어 있는 곳이 없기 때문에 재사용과 테스트에 용이하다.
하지만 Controller입장에서는 Model에 대한 의존성이 생기고 View와 매우 강하게 결합된다. 따라서 Controller에는 많은 코드가 쌓일 수 있다는 단점이 있다.
Model은 View와 연결된 부분 없어 의존성 없이 독립적이다. 대신에 데이터를 가지며, 데이터 변경이 가능한 함수로 구성되어 있다. 이렇게 데이터와 가공을 담당하고 있기 때문에 Controller에서는 해당 임무를 Model에 완전히 맡겨야 한다.
2. MVP (Model, View, Presenter)
Model
MVC에서의 Model과 기능과 역할이 같다.
View
MVC에서와 마찬가지로 UI 요소를 담당한다. 하지만 UI 갱신과 같은 작업을 View에서 직접 처리해야하기 때문에 Activity와 Fragment도 View로 분류한다. 즉, Presenter가 UI 갱신을 View에게 요청한다는 것이다.
MVC에서는 Controller로 분류되어 있던 Activity나 Fragment가 UI 갱신을 했다. 이러한 것들이 MVP에서는 View로 분류가 되었으니, View에서 UI 갱신을 하게된 것이다.
추가로 Controller가 Model과 상호작용을 했었는데, 이제 이 역할을 하던 Activity와 Fragment가 View에 포함되었으니, Model과 상호작용은 직접 하지 않는다. 대신에 그 역할은 Presenter가 대신하게 된다. 따라서 View와 Presenter 간에 의존성이 생기게 된다.
이때 Presenter가 Activity와 직접 연결되지 않도록 View Interface를 만들고 Activity가 Implements 하여 해당 Interface로 연결하면 가상의 View Interface로 가상의 객체를 만들 수 있어 Presenter 로직 테스트에 용이하다.
Presenter
MVC의 Controller 역할과 유사하다.
Model과 상호작용하고, View에 UI 갱신을 요청한다. 다만 직접 UI를 갱신하는 것이 아니라 어떤 것을 보여줘야 하는 지에 대한 정보만 View에 전달한다. 실제 UI 갱신은 View에 맡기는 것이다.
즉, Presenter는 Controller와 다르게 View와 직접적으로 연결되는 것이 아니라 가교 역할만 한다는 것이다.
View와의 의존성은 여전히 남아있고, Model과의 의존성도 있다.
MVP 정리
View와 Model은 여전히 분리되어 있다.
Model은 종속되어 있는 곳이 없기 때문에 재사용과 테스트에 용이하다.
하지만 Presenter는 View와 Model에 대한 의존성이 생긴다. View 또한 Presenter와 의존성이 생긴다. 즉, Presenter와 View는 서로 의존성이 생긴다.
MVC에서의 Controller와 마찬가지로 Presenter에 많은 코드가 쌓이게 될 수 있다는 단점이 있다.
Presenter가 할 일이 계속 늘어나면 결국 코드가 비대해지는데, Interface를 구현하였기 때문에 가상의 View나 다른 View를 통해서 Presenter 로직 테스트를 하기 쉽다는 장점이 있다.
