[안드로이드/Android] 디자인패턴 MVP / MVC / MVVM 을 비교해보자.

🪴 들어가기에 앞서

MVC, MVP, MVVM 패턴은 소프트웨어 개발에서 주로 사용되는 아키텍처 디자인 패턴이므로, 이정도는 숙지하고, 흐름이 어떻게 진행되는지 알아보고, 각각의 장단점을 파헤쳐 보자.

 

🪴 디자인 패턴이란 ?

소프트웨어 디자인에서 공통적인 문제를 해결하기 위해 재사용이 가능한 해결책이다. 이러한 패턴은 개발자들 사이에서 검증되고 테스트된 설계 아이디어와 방법론의 집합을 의미하는데, 디자인 패턴을 사용하면 소프트웨어 시스템을 구축하고 유지보수 하데 도움이 되는 구조화된 접근 방식을 제공한다. 

 

1. 디자인 패턴의 세 가지 범주

• 생성(Creational) 패턴 : 객체의 인스턴스화 과정을 다루는 패턴이다. 이러한 패턴은 객체를 생성, 조립 및 표현하는 방법에 초점을 둔다. 대표적인 예로 싱글턴(Singleton), 팩토리(Factory), 추상 팩토리(Abstract Factory) 등이 있다.
• 구조(Structural) 패턴 : 클래스와 객체를 조합하여 더 큰 구조를 형성하는 패턴이다. 이러한 패턴은 클래스 및 객체 간의 관계를 다루며, 상속, 합성 등을 활용하여 시스템의 구조를 생성한다. 대표적인 예로 어댑터(Adapter), 데코레이터(Decorator), 컴포지트(Composite) 등이 있다.
• 행위(Behavioral) 패턴 : 객체 간의 상호 작용과 책임 분배에 초점을 둔 패턴이다. 이러한 패턴은 객체 간의 효율적인 통신과 작업 분담을 위해 사용된다. 예로는 옵저버(Observer), 전략(Strategy), 커맨드(Command) 등이 있다.

 

2. 디자인 패턴의 장점

• 재사용성(Reusability) : 디자인 패턴은 검증된 솔루션을 제공하므로 코드 재사용성을 높일 수 있다. 패턴을 사용하면 이미 존재하는 디자인 아이디어와 구조를 활용해 비슷한 문제를 해결할 수 있으며 이로인해 개발 시간 단축과 유지보수 비용을 줄일 수 있다.
• 확장성(Scalability) : 디자인 패턴은 시스템을 쉽게 확장하고 유연하게 변경할 수 있는 구조를 제공한다. 새로운 요구사항이나 기능 추가에 대해 패턴을 활용하면 기존 코드를 크게 수정하지 않고도 변경을 수용할 수 있다. 이는 시스템의 확장성과 유연성을 확장하는데 도움이 된다.
• 구조화된 접근 방식(Structured Approach) : 디자인 패턴은 일반적인 문제 해결을 위한 구조화된 접근 방식을 제공한다. 패턴은 설계 원칙과 모범 사례를 포함하고 있어 개발자들 사이에서 공통된 언어와 용어를 제공한다. 이는 팀의 협업을 원활하게 하고 코드의 가독성과 이해도를 높여준다.
• 유지보수성(Maintainability) : 디자인 패턴은 소프트웨어 시스템을 구조화하고 모듈화하는데 도움을 준다. 이는 코드의 가독성을 높이고 유지보수를 용이하게 만들어준다. 패턴을 사용하면 변경이 필요한 부분을 식별하고 수정하기 쉬워지며, 코드의 일관성과 견고성을 유지할 수 있다.
• 설계 품질 개선(Quality Improvement) : 디자인 패턴을 사용하면 품질이 좋은 소프트웨어를 설계할 수 있다. 패턴은 설계 원칙을 적용하고 구조적인 결합도와 응집도를 강화한다. 이는 유연하고 확장 가능한 시스템을 만들 수 있으며, 버그와 에러의 발생 가능성을 줄인다.
• 문제 해결 지침(Problem-Sobing Guidelines) : 디자인 패턴은 일반적인 디자인 문제에 대한 해결책을 제공한다.

 

---

 

🪴 MVC (Model-View-Controller) 패턴

MVC패턴은 모델(Model), 뷰(View), 컨트롤러(Controller)로 구성되며, 소프트웨어를 세 가지 구성 요소로 분리하여 개발하는 데 초점을 둔다.

• Controller는 여러개의 View를 선택할 수 있는 1:N 구조이다.
• Controller는 View를 선택할 뿐 직접 업데이트 하지 않으며, View는 Controller를 알지 못한다.

 

 

MVC 패턴

 

[1] 구조

• Model : 어플리케이션에서 사용되는 데이터와 비지니스 로직을 처리하는 부분이다.
• View : 사용자 인터페이스를 표시한다.
• Controller : 모델과 뷰 사이의 상호 작용을 관리하며 사용자의 입력(Action)을 처리하고, 모델 상태를 업데이트한다.

 

[2] 동작

1. 사용자의 Action들은 Controller에 들어오게 됩니다.
2. Controller는 사용자의 Action을 확인하고, Model을 업데이트한다.
3. Controller는 Model을 나타내줄 View를 선택한다.
4. View는 Model을 이용하여 화면을 나타낸다.

 

[3] 장점

• MVC의 가장 큰 장점은 '모델에서 데이터를 가져와 뷰에 표현을 하고 컨트롤러를 통해 이벤트가 발생하면 모델과 뷰를 갱신'이라는 구조로 직관적이며 단순하다
• MVC 디자인 패턴을 잘 모르더라도 소스코드만 봐도 이해가 쉽고, 실제로도 안드로이드 API를 이용한 코드를 그냥 작성하더라도 MVC 패턴으로 볼 수가 있다
• 구조가 단순하니 작은 애플리케이션을 개발하는데 크게 신경쓰지 않고 개발을 빠르게 진행시킬 수 있다.

 

[4] 단점

• 구조가 단순한 만큼 Activity, Fragment에 모든 코드가 편중되어 있는 경향이 있으며, 애플리케이션의 규모가 점차 커지면 하나의 클래스에 방대한 코드들이 생겨 과부하될 수 있다.
• 또한 스파케티 코드들을 양산하게 되고 단순하게 파알할 수 있다는 장점이 하나의 클래스에 집중이 되면서 단점으로 바뀔 수도 있다
• 컨트롤러는 특정 뷰와 모델에 의존적이며, 뷰도 특정 모델에 의존적이라서 결합도가 높아져 유닛테스트가 거의 불가능하다.

 

---

🪴 MVP (Model-View-Presenter) 패턴

MVP 패턴은 모델(Model), 뷰(View), 프래젠터(Presenter)로 구성되며, 이 패턴은 사용자 인터페이스(UI)와 비즈니스 로직을 분리하여 개발하는데 중점을 둔다.  이 패턴은 테스트 용이성과 유지보수성을 개선할 수 있다. 또한 UI와 비즈니스 로직의 분리로 다른 플랫폼에 재사용이 가능하다. 

• Presenter와 View는 1:1 관계이다.
• Presenter는 View와 Model의 인스턴스를 가지고 있어 둘을 연결하는 접착제 역할을 한다.

 

MVP 패턴

 

[1] 구조

• Model : 데이터와 비즈니스 로직을 처리한다.
• View : 사용자 인터페이스를 표시하고, 사용자 입력을 처리한다.
• Presenter : 모델과 뷰 사이의 중간 역할로, 비즈니스 로직을 처리하고 뷰에 데이터를 전달하며 사용자 입력을 처리한다.

 

 

[2] 동작

1. 사용자의 Action들이 View를 통해 들어온다.
2. View는 데이터를 Presenter에 요청한다.
3. Presenter는 Model에 데이터를 요청한다.
4. Model은 Presenter에게 요청받은 데이터를 응답하여 넘겨준다.
5. Presenter는 View에게 데이터를 넘겨준다.
6. View는 Presenter가 응답한 데이터를 화면에 나타낸다

 

 

[3] 장점

• MVC의 View(Activity, Fragment)에서는 모델을 직접 생성하여 변경하는데 의존적이었지만, MVP에서는 View와 Model 중간에서 Presenter라는 연결고리를 두어 결합도를 약하게 만들었기 때문에 유닛테스트가 수월하다.

 

[4] 단점

• View에서 Presenter를 직접 생성하기에 의존성이 높고 1:1 관계를 유지해야해서 View가 많아질수록 Presneter도 자연스럽게 많아질 수 밖에 없다.
• View와 Model은 연결시켜주는 역할이 Presenter이기 때문에 애플리케이션 기능이 추가될때마다 Presenter 내의 코드도 많아지는 단점이 있다.

 

---

🪴 MVVM (Model-View-ViewModel) 패턴

이 패턴은 사용자 인터페이스(UI), 비지니스 로직, 데이터를 분리하여 개발하는 데 중점을 둔다. 주로 클라이언트측의 웹과 모바일 애플리케이션 개발에서 많이 사용된다. 이 패턴의 중요한 개념은 데이터 바인딩이며,  데이터 바인딩은 뷰와 뷰모델 간의 자동화된 데이터 동기화를 제공한다. 이는 뷰가 데이터 변경 사항을 실시간으로 반영하고, 뷰모델의 변경 사항을 뷰로 전달할 수 있도록 한다.

• MVVM패턴은 View와 Model 사이의 의존성이 없다.
• Command패턴과 Data Binding을 사용하여 View와 View Model 사이의 의존성 또한 없앴다.
• 각각의 부분은 독립적이기 때문에 모듈화하여 개발할 수 있다.

 

 

MVVM 패턴

 

[1] 구조

• Model
  • 데이터와 비지니스 로직을 처리한다.
  • 애플리케이션의 상태와 도메인 데이터를 관리한다.
  • 보통은 데이터베이스, API 호출 등과 상호 작용한다.
• View
  • 사용자 인터페이스(UI)를 표시한다.
  • 사용자와의 상호 작용을 처리하고, 사용자 입력을 받아들이고, 결과를 표시한다.
  • 주로 UI 컴포넌트(화면, 페이지, 위젯)로 구성된다.
• ViewModel
  • 뷰와 모델 사이의 중간 역할을 수행한다.
  • 뷰에 표시할 데이터를 제공하고, 뷰에서 발생하는 이벤트 및 명령을 처리한다.
  • 데이터 바인딩을 통해 뷰와의 상호작용을 단순화한다.
  • 뷰에 특화된 데이터 포맷이나 표현을 제공하기도 한다.

 

[2] 동작

1. 사용자의 Action들은 View를 통해 들어온다.
2. View에 Action이 들어오면, Command 패턴으로 ViewModel에 Action을 전달한다.
3. ViewModel은 Model에게 데이터를 요청한다.
4. Model은 ViewModel에게 요청받은 데이터를 응답한다.
5. ViewModel은 응답받은 데이터를 가공하여 저장한다.
6. View는 ViewModel과 Data Binding하여 화면을 나타낸다.

 

[3] 장점

• View와 ViewModel 사이의 결합도가 느슨하여 유닛테스트를 수행할 수 있다.
• 또한, View와 Model 사이에서도 의존성이 없다.
• View는 ViewModel을 알지만 ViewModel은 View를 알지 못하고 ViewModel은 Model을 알지만 Model은 ViewModel을 알지 못한다. 즉, 한쪽 방향으로만 의존관계가 있어 각 모듈별로 분리하여 개발에 용이하다.

[4] 단점

• 다른 디자인 패턴에 비해 코드 설계가 복잡하다.
• DataBinding, LiveData 등 다른 라이브러리를 필수적으로 알아야 사용할 수 있다는 단점이 있다.

 

---

옛날 안드로이드 할때 MVVM 설계할 때 어렵고, 이해안하고, 복잡했었는데 면접에서 오랜만에 MVP와 MVVM의 차이점에 대해서 질문을 받았는데, 당황해서 절어버렸다.. 이미지 유형만 구상화해도 대답은 잘 나올 수 있게끔 인지해두자