본문 바로가기
Mobile App

[안드로이드] - MVC 패턴과 안드로이드 MVC 패턴

by Jman 2023. 2. 15.

MVC 

제록스 팰러앨토 연구소에서 스몰토크 관련 일을하던 Trygve Reenskaug 이 1979년 최초로 소개를 했다.

MVC 패턴은 이름에서도 알 수 있듯이 모델(Model), 뷰(View), 컨트롤(Controller) 세 개의 컴포넌트로 이루어져있다. 각 컨포넌트는 고유한 역할을 수행한다.

MVC 패턴 다이어그램

모델(Model)

데이터 가공을 책임지는 컴포넌트를 말한다.

모델은 애플리케이션의 정보, 데이터를 나타낸다. 데이터베이서, 처음 정의하는 상수, 초기화 값, 변수 등을 뜻한다.

비즈니스 로직을 처리한 후 모델의 변경사항을 컨트롤러와 뷰에 전달한다.

 

모델은 다음과 같은 규칙을 가지고 있다.

  • 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
  • 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다.
  • 변경이 일어나면, 변경 통지에 대한 처리방법도 구현이 필요하다.

뷰(View)

사용자에게 보여지는 부분, 즉 유저 인터페이스를 의미한다.

MVC 패턴은 여러 개의 뷰(View) 가 존재할 수 있고, 모델에게 질의하여 데이터를 전달 받아, 데이터를 화면에 표시해주는 역할을 한다.

또한 사용자가 화면에서 표시된 내용을 변경하게 되면, 모델에게 전달하여 모델을 변경해야 한다.

 

뷰는 다음과 같은 규칙을 가지고 있다.

  • 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
  • 모델이나 컨트롤러를 몰라야 된다.
  • 사용자 인터페이스로 인해 변경된 값을 처리가 필요하다.

컨트롤러(Controller)

모델과 뷰 사이를 이어주는 중간 브릿지 역할을 의미한다.

모델이나 뷰는 서로의 존재를 모르고 있다. 변경 사항을 외부로 알리고 수신하는 방법만 있다.

컨트롤러는 이를 중재하기 위해 모델과 뷰에 대해 알고 있고, 모델과 뷰로부터 변경 내용을 통지 받으면 이를 각 컴포넌트에게 통지를 한다.

사용자가 어플리케이션을 조작하여 발생하는 변경 이벤트들을 처리하는 역할을 수행한다.

  • 모델이나 뷰에 대해서 알고 있어야 한다.
  • 모델이나 뷰의 변경을 모니터링 해야 한다.

 

MVC 패턴은 왜 사용할까?

간단하게 말하면 유지보수의 편리성 때문에 우리는 MVC 패턴을 사용한다.

커플링이 높은 시스템은 유지보수 작업 시 다른 비즈니스 로직에 영향을 미쳐 의도치 않은 에러가 발생할 수 있다.

이를 MVC 패턴을 적용하여 각 컴포넌트를 분리하여 비즈니스 로직과 UI 로직을 분리하면 유지보수를 독립적으로 수행할 수 있게 만든다.

또한 Model 과 View 각각이 다른 컴포넌트에 종속되지 않아, 애플리케이션의 확장성과 유연성에 유리하고 중복 코딩의 문제점을 없앤다.

 

MVC 한계

우리는 MVC 패턴 이외에 여러 패턴을 들어본 적이 있을 것이다. MVP, MVVM, MVW 등등

다른 디자인 패턴이 만들어지는 건 MVC 패턴의 한계 때문에 나오게 됐다.

 

MVC 패턴은 View 와 Controller 에 연결되어 화면을 구성하는 단위요소이므로 다수의 View 를 가질 수 있다.

그리고 Model은 Controlller 통해서 View 와 연결되지만, Controller 에 의해서 하나의 View에 연결될 수 있는 Model의 수가 여러 개가 될 수가 있다. 따라서 View 와 Model 이 서로 의존성을 띄게 된다.

 

즉, Controller 에 다수의 Model 과 View 가 복잡하게 연결되어 있는 상황이 발생한다.

그리되면 Controller 는 비대해지고 불필요하게 커지는 현상이 발생한다. 아래의 그림을 참고하자.

 

Massvie-View-Controller

 

안드로이드 MVC 패턴은?

무슨 안드로이드만 MVC 패턴이 다르다고 이렇게 따로 정리를 하냐. 라는 생각을 할 수 있다.

우리가 흔히 MVC 패턴을 생각하면 Web Application MVC 패턴을 생각할 것이다.

쓰니도 그랬다. 쓰니는 백엔드 개발을 했을 당시 Spring MVC 패턴이 익숙한 상태에서 안드로이드 개발을 할때, 응? 이게뭐지 라는 생각에 사로잡혔다. 각 컴포넌트 구분이 안됐다는 뜻이다.

무엇이 다른지 설명해보겠다.

WEB Application

우리가 MVC 패턴을 웹 애플리케이션에서 맞게 사용할 때 Flow 다.

이렇게 보면 위에서 설명한대로 MVC 각 컴포넌트 역할에 맞게 수행되는 것을 볼 수 있다.

 

그러면 안드로이드는 어떻게 될까? 

안드로이드 개발을 조금이라도 해보면 View가 무엇인지 헷갈릴 것이다.

xml 파일 View 가 존재하고 View(Activity/Fragment)Class 파일도 존재한다. 둘 다 그냥 View 다. 따라서 웹이랑 좀 다르다.

 

아래 그림을 보자.

Android Mobile Application

MVC 패턴이라, 모델과 뷰를 분리함으로써 모델이 어디에도 종속되지 않지만 뷰와 컨트롤러가 한 곳에 공존한다는 것을 알 수가 있다.

둘이 공존하기에 한 곳에서 편하게 구현이 가능하다는 장점이 있지만, 컨트롤러의 책임이 너무 많아진다. 따라서 컨트롤러가 비대해진다.

 

컨트롤러 문제점

  • 테스트가 쉽지않다 - 컨트롤러가 안드로이드 API 에 깊게 종속되므로 단위 테스트가 어렵다.
  • 모듈과 유연성 측면에서 좋지 않다 : 컨트롤러가 뷰에 단단히 결합되며, 뷰의 확장일 수도 있다. 따라서 뷰를 변경하면 컨트롤러로 돌아가서 코드 변경을 해줘야 한다.
  • 유지 보수가 좋지 않다 - 시간이 지나 많은 코드가 컨트롤러에 모이면 비대해져 문제가 발생해지고 anemic models 을 사용하는 앱일 수록 더더욱 그렇다.

💡anemic models 란? 빈약한 도메인 모델로 번역할 수 있다. 모델에 비즈니스적으로 유믜한 내용을 가지 않고 소위 말하는 게터/세터만 있는 객체를 말한다. 

 

 

정리

MVC 패턴도 노아키텍처 코드보다 훨씬 구조적이고 유지보수에 용이하며, Model 과 뷰를 분리해주는 부분에서 굉장히 좋은 아키텍처이다.

하지만 위에서 언급했듯이 문제가 있다.

빠른 개발을 위해서 MVC 패턴을 적용하여 제품을 출시해도 좋지만, 유지보수 측면을 고려해서 해당 패턴을 적용할지에 대해 많은 고민이 필요한 것 같다.