이번에는 Android MVP 따라하기 두번째 Step으로 MVC 구조를 알아보려 한다. MVC 구조로 작성된 코드를 하나씩 MVP 구조로 변경하기 위함이다.

MVC 구조

MVC는 MVP 이전의 구조 중 하나이다. Model, View, Control의 약자로 주로 웹에서 사용되는 구조이다. 그래서 Android에 적용된 구조는 조금 다른 형태로 표현된다.

MVC는?

Model, View, Control의 약자이다. MVC는 주로 웹에서 사용하고, 가장 널리 사용되는 구조 중 하나이다. MVC 구조에서의 입력은 모두 Control에서 발생하게 되는 구조이다. 이벤트가 발생한 Control에 의해 모듈의 정의와 View의 용도가 결정된다.

  • Model : 데이터를 가진다.
  • View : 사용자에게 보일 화면을 표현한다.
  • Control : 사용자로부터 입력을 받고, 이를 모델에 의해 View를 정의하게 된다.
  1. Control : 사용자 이벤트 발생
  2. Control : 사용자 이벤트가 발생하였는데 갱신이 필요한지 Model에 확인
  3. Model : 데이터 갱신이 필요하다는 이벤트 발생
  4. View : Model 또는 Control로부터 갱신 필요 여부 이벤트를 받는다.
  5. View : Model에서 실제 필요한 데이터를 받아와 View를 갱신

위와 같은 5단계 정도로 나열할 수 있을 것이다.

하지만 Android에서는?

Android에서는 View와 Control이 Activity/Fragment 같은 View들이 모두 가지고 있다. 예를 들면 아래와 같은 코드가 될 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class MainActivity extends AppCompactActivity {

@Override
protected void onCreate(Bundle savedInstanceState) {
// ...

FloatingActionButton fab = (FloatingActionButton) findViewById(R.id.fab);
fab.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View view) {
// 데이터 갱신 요청
// Model에 접근해서 최신 데이터를 요청
// ex) ArrayList<String> getItems()
// 전달받은 ArrayList를 통해 View를 갱신
}
});
}
}

하나의 화면 안에서 Control인 setOnClickListener이 발생하고, 이를 View에서 모두 처리하는 형태이다. Web에서 적용된 MVC 패턴은 View와 Control이 모두 분리된 상태를 말한다. 하지만, 안드로이드는 위와 같다. 그래서 그림으로 정리해보면 아래와 같을 수 있다.

간단하게 정리해보면 아래와 같다.

  1. Activity에서 사용자 이벤트 발생
  2. Model로부터 데이터 갱신이 필요한지 확인
  3. Model로부터 전달받은 데이터를 통해 View 갱신 여부 판단
  4. View에서 UI 갱신 처리

한 화면에서 모든 데이터를 처리함으로써 얻는 장점

Android에서 흔하게 사용되는 MVC는 Class 하나로 처리가 가능한 구조가 만들어지게 된다. 그렇기에 정리만 잘하면 한눈에 코드 파악이 가능할 수 있지만, 어느 정도 범주를 벗어나면 코드 파악이 어렵다. 함수 분리가 안되어 있다면 더욱 그렇다.

그렇기에 함수 분리 또는 Class 분리를 적절하게 해야 복잡도가 낮아질 수 있다. 예를 들면 아래와 같이…

1
2
3
boolean isLast(){
return itemList.size() >=100;
}

그 외에도 공통으로 분리될 수 있어 보이는 setVisibility()도 여러 번 Visible/Gone이 발생한다면 당연히 함수로 분리한다. 그렇기에 코드 분리만 잘해도 사실 MVC 패턴으로 코드 작성은 문제가 없다.(고 한다… 나는 계속 MVC로 프로젝트를 작성했다.)

장점

  1. 개발 기간이 짧을 수 있다.
    생각보다 개발 기간이 짧을 수 있다. 생각해야 할 부분도 많지 않고, 그냥 Android Activity에서 모든 걸 동작하게 처리만 해주면 되므로, 개발 기간이 짧을 수 있다.
  1. 코드만 읽을 수 있다면 누구나 쉽게 파악 가능
    그리고 처음 보는 사람도 별도의 패턴을 구분하지 않고, 쉽게 파악이 가능하다.

단점

  1. 코드의 양이 증가
    하나의 Class 안에서 모든 걸 할 수 있다. 그로 인해 하나의 Class에서 수백 ~ 수천 줄이 넘는 코드를 발견할 수 있다.
  1. 스파게티 코드 가능성
    복사 / 붙여넣기가 많아지고, 코드 분리가 안되어 있다면 스파게티 코드처럼 빙빙 꼬여 있는 모습을 볼 수 있다. 그렇기에 복잡도는 증가한다. 결국 처음 설계부터 중요하고, 분리도 잘해야 한다.
  1. 유지 보수의 어려움
    개발 기간이 짧다는 말은 그만큼 코드를 막 작성할 수 있다는 말이고, 코드의 정체성이 혼란이 생길 수 있다. 꾸준하게 이런 일이 발생하게 되면 쓰레기 코드의 양 증가를 동시에 가져오게 된다. 이러한 이유들로 유지 보수 역시 어려워지게 된다.
  1. View와 Model의 결합도가 높다.
    MVC는 View와 Model간의 결합도가 높다. 대부분의 코드를 View에서 Model을 직접 호출하여 사용하게 된다. 그렇기에 View와 Model 간의 결합도가 높아지게 되고, 테스트 코드 작성에도 어려움이 발생한다.
  1. 테스트 코드 작성이 어렵다.
    MVC는 대부분 UI에서 모든 걸 할 수 있기 때문에 테스트 코드 작성이 어려워지게 된다. 작성을 한다고 하더라도 UI 위주의 테스트 코드 작성이 가능하다. 하지만 UI는 변화가 자주있는 곳 중에 하나이다. UI가 아닌 모델까지 변경이 된다면…

참고