[Android] MVP 따라하기 2
이번에는 Android MVP 따라하기 두번째 Step으로 MVC 구조를 알아보려 한다. MVC 구조로 작성된 코드를 하나씩 MVP 구조로 변경하기 위함이다.
MVC는 MVP 이전의 구조 중 하나이다. Model, View, Control의 약자로 주로 웹에서 사용되는 구조이다. 그래서 Android에 적용된 구조는 조금 다른 형태로 표현된다.
MVC는?
Model, View, Control
의 약자이다. MVC는 주로 웹에서 사용하고, 가장 널리 사용되는 구조 중 하나이다. MVC 구조에서의 입력은 모두 Control에서 발생하게 되는 구조이다. 이벤트가 발생한 Control에 의해 모듈의 정의와 View의 용도가 결정된다.
- Model : 데이터를 가진다.
- View : 사용자에게 보일 화면을 표현한다.
- Control : 사용자로부터 입력을 받고, 이를 모델에 의해 View를 정의하게 된다.
- Control : 사용자 이벤트 발생
- Control : 사용자 이벤트가 발생하였는데 갱신이 필요한지 Model에 확인
- Model : 데이터 갱신이 필요하다는 이벤트 발생
- View : Model 또는 Control로부터 갱신 필요 여부 이벤트를 받는다.
- View : Model에서 실제 필요한 데이터를 받아와 View를 갱신
위와 같은 5단계 정도로 나열할 수 있을 것이다.
하지만 Android에서는?
Android에서는 View와 Control이 Activity/Fragment
같은 View들이 모두 가지고 있다. 예를 들면 아래와 같은 코드가 될 수 있다.
1 | public class MainActivity extends AppCompactActivity { |
하나의 화면 안에서 Control인 setOnClickListener이 발생하고, 이를 View에서 모두 처리하는 형태이다. Web에서 적용된 MVC 패턴은 View와 Control이 모두 분리된 상태를 말한다. 하지만, 안드로이드는 위와 같다. 그래서 그림으로 정리해보면 아래와 같을 수 있다.
간단하게 정리해보면 아래와 같다.
- Activity에서 사용자 이벤트 발생
- Model로부터 데이터 갱신이 필요한지 확인
- Model로부터 전달받은 데이터를 통해 View 갱신 여부 판단
- View에서 UI 갱신 처리
한 화면에서 모든 데이터를 처리함으로써 얻는 장점
Android에서 흔하게 사용되는 MVC는 Class 하나로 처리가 가능한 구조가 만들어지게 된다. 그렇기에 정리만 잘하면 한눈에 코드 파악이 가능할 수 있지만, 어느 정도 범주를 벗어나면 코드 파악이 어렵다. 함수 분리가 안되어 있다면 더욱 그렇다.
그렇기에 함수 분리 또는 Class 분리를 적절하게 해야 복잡도가 낮아질 수 있다. 예를 들면 아래와 같이…
1 | boolean isLast(){ |
그 외에도 공통으로 분리될 수 있어 보이는 setVisibility()도 여러 번 Visible/Gone이 발생한다면 당연히 함수로 분리한다. 그렇기에 코드 분리만 잘해도 사실 MVC 패턴으로 코드 작성은 문제가 없다.(고 한다… 나는 계속 MVC로 프로젝트를 작성했다.)
장점
- 개발 기간이 짧을 수 있다.
생각보다 개발 기간이 짧을 수 있다. 생각해야 할 부분도 많지 않고, 그냥 Android Activity에서 모든 걸 동작하게 처리만 해주면 되므로, 개발 기간이 짧을 수 있다.
- 코드만 읽을 수 있다면 누구나 쉽게 파악 가능
그리고 처음 보는 사람도 별도의 패턴을 구분하지 않고, 쉽게 파악이 가능하다.
단점
- 코드의 양이 증가
하나의 Class 안에서 모든 걸 할 수 있다. 그로 인해 하나의 Class에서 수백 ~ 수천 줄이 넘는 코드를 발견할 수 있다.
- 스파게티 코드 가능성
복사 / 붙여넣기가 많아지고, 코드 분리가 안되어 있다면 스파게티 코드처럼 빙빙 꼬여 있는 모습을 볼 수 있다. 그렇기에 복잡도는 증가한다. 결국 처음 설계부터 중요하고, 분리도 잘해야 한다.
- 유지 보수의 어려움
개발 기간이 짧다는 말은 그만큼 코드를 막 작성할 수 있다는 말이고, 코드의 정체성이 혼란이 생길 수 있다. 꾸준하게 이런 일이 발생하게 되면 쓰레기 코드의 양 증가를 동시에 가져오게 된다. 이러한 이유들로 유지 보수 역시 어려워지게 된다.
- View와 Model의 결합도가 높다.
MVC는 View와 Model간의 결합도가 높다. 대부분의 코드를 View에서 Model을 직접 호출하여 사용하게 된다. 그렇기에 View와 Model 간의 결합도가 높아지게 되고, 테스트 코드 작성에도 어려움이 발생한다.
- 테스트 코드 작성이 어렵다.
MVC는 대부분 UI에서 모든 걸 할 수 있기 때문에 테스트 코드 작성이 어려워지게 된다. 작성을 한다고 하더라도 UI 위주의 테스트 코드 작성이 가능하다. 하지만 UI는 변화가 자주있는 곳 중에 하나이다. UI가 아닌 모델까지 변경이 된다면…