[Architecture Pattern] MVC 패턴

이때까지 프로젝트를 하면서 코드가 복잡해지는 것에 대한 불편함을 느꼈다. 디자인 패턴을 적용하지 않고, UI 설정 코드와 데이터 받아오는 코드 등을 합쳐놓으니 굉장한 스파게티 코드가 된 것 같았다... 따라서 앞으로 하는 프로젝트는 모듈화와 디자인 패턴 적용에 집중해야 겠다고 생각했다. 여러 아키텍처 패턴 중 심플하다고 생각되는 MVC 패턴부터 알아보고자 한다.

 

해당 포스팅은 안드로이드 아키텍처 기준으로 작성되었습니다.

1. MVC 패턴이란?

MVC 패턴은 애플리케이션(응용 프로그램)을 서로 다른 역할로 분리해놓은 패턴 중 하나이다. 관심사 분리(Separation of Concerns, SoC)로도 알려져 있다고 한다.

 

여기서 관심사 분리(separation of concerns, SoC)란?

In computer science, separation of concerns is a design principle for separating a computer program into distinct sections. 출처 : 위키백과

SoC를 컴퓨터 과학에서는, 컴퓨터 프로그램을 섹션별로 구분하여 분리해놓은 디자인 원칙을 말한다.

 

MVC 패턴은 Model, View, Controller 이 세 가지 역할로 컴퓨터 프로그램을 분리해놓은 것이다.

주로 웹에서 많이 사용하며, 가장 많이 사용되는 패턴 중 하나다.

 

 

2. MVC 패턴의 구조

1.MVC 패턴이란?에서 언급했듯이, MVC 패턴은 세 가지 역할로 구성되어 있다.

 

출처 : https://code.tutsplus.com/tutorials/an-introduction-to-model-view-presenter-on-android--cms-26162

 

 

Model

• 프로그램에서 다루는 데이터를 가지고 있고 그 데이터를 처리하는 부분
• 데이터 처리하는 역할

View

• UI 부분 (안드로이드에서는 Activity, Fragment, ... 등등)
• 사용자에게 결과 출력하여 보여주는 부분
• Model의 데이터 상태를 인지하여 화면에 표시 ex)Model으로부터 받아온 데이터의 변경이 있을 경우 이를 인지하여 View를 업데이트 할 수 있다. 혹은 Model에서 데이터의 변경을 View에게 알린다음 View가 업데이트되는 방법도 있다.
• 렌더링하는 역할

Controller

• 사용자의 입력을 받고 처리하는 부분. 사용자의 입력을 Model을 통해 처리하여 View에 나타낸다. 
• 데이터를 처리할 Model을 결정한다.
• 결과를 나타낼 View를 결정한다.

동작 순서

1. Controller로 사용자의 입력이 들어온다.
2. Controller는 Model의 데이터를 업데이트하고 Model을 호출한다.
3. Controller는 Model을 나타낼 View를 선택한다.
4. View는 Model 통해 화면에 데이터를 나타낸다.

 

3. 장점

• 역할 분담으로 프로그램의 독립성이 높아진다. 개발 환경 변경에도 유연하게 대응할 수 있다.
• 비교적 단순한 구조로, 쉽게 분리할 수 있다.

 

4. 문제점

• View와 Model 사이의 의존하는 정도가 높다.
  • 모듈 간의 결합도가 높아지면 프로그램이 커질 수록 유지 보수가 어렵게 된다는 문제가 있다.
• 입력에 따른 출력의 조건이 복잡해질 수록 View와 Controller의 의존성이 높아질 수 있다.

 

간단해서 아키텍처 패턴 입문하는 용으로 쉽게 적용할 수 있지 않을까 싶다.

비교적 큰 프로젝트에서는 사용하면 문제점이 많을 패턴 같기도 하다.

 

 

참조

• Qiita(MVC とは何かを 1 から学ぶ)
• 버미노트([디자인패턴] MVC,MVP, MVVM  비교)
• envatotuts+(An Introduction to Model View Presenter on Android)