디자인 패턴
- 소프트웨어 공학에서 디자인 패턴은 소프트웨어 디자인에서 흔히 발생하는 문제에 대한 일반적인 반복 가능한 해결책
- 디자인 패턴은 코드로 직접 변환될 수 있는 완성된 디자인이 아니라, 다양한 상황에서 사용할 수 있는 문제 해결 방법에 대한 설명 또는 템플릿
- 안드로이드 개발에서는 주로 MVC, MVP, MVVM 패턴을 사용
1. MVC
1) MVC란?
Model, View, Controller 구조의 패턴
Model
-> 비지니스 로직과 데이터를 다루는 영역
View
-> 사용자에게 보여지는 영역
Controller
-> Model과 View 중간에서 상호작용을 관리하는 영역2) MVC 동작
사용자Action -> Controller
Controller -> Model
Model -> View
View -> 사용자 화면
3) MVC 장점
직관적인 코드
Model의 비종속성으로 재사용 가능
개발기간이 상대적으로 짧음
4) MVC 단점
Model과 View사이의 의존성
-> 애플리케이션이 커지고 로직이 복잡할수록 유지보수가 어려워짐Controller에 코드가 집중적으로 쌓여 알아보기 힘들 수 있음
2. MVP
1) MVP란?
Model, View, Presenter 구조의 패턴
MVC 패턴에서 Activity, Fragment는 컨트롤러 역할과 뷰 역할을 동시에 하기에 UI 로직이 공존
MVP 패턴에서는 이처럼 UI 로직과 비즈니스 로직을 분리하는데 집중하여 생겨난 디자인 패턴
Model
-> 비지니스 로직과 데이터를 다루는 영역
View
-> 사용자에게 보여지는 영역
-> MVP에서의 Activity와 Fragment는 View역할만 함
Presenter
-> View와 Model을 연결해주는 역할
-> UI 로직과 비즈니스 로직을 분리할 수 있게 됨
-> Presenter 내에는 Model과 View의 인스턴스를 가짐
-> Presenter와 View는 1:1 관계2) MVP 동작
- Action -> View
- View는 데이터를 Presenter에 요청
- Presenter는 Model에 데이터를 요청
- Model은 Presenter에서 요청받은 데이터를 응답
- Presenter -> View
- View는 받은 데이터를 이용하여 화면을 나타냄
3) MVP 장점
- Presenter를 통해 Model과 View의 결합도가 낮음
- 기능 추가 및 변경 시 관련 부분만 수정하면 되어 확장성이 개선
4) MVP 단점
- View에서 Presenter를 직접 생성하기에 의존성이 높음
- View가 많아질 수록 Presenter도 많아짐
3. MVVM
1) MVVM이란?
- Model, View, View Model 구조의 패턴
- Command패턴과 Data Binding 패턴을 사용하여 구현
-> View와 View Model 사이의 의존성을 없앰- View Model과 View는 1:n 관계
Model
-> 비지니스 로직과 데이터를 다루는 영역
View
-> 사용자에게 보여지는 영역
View Model
-> View를 표현하기 위해 만든 View를 위한 model
-> View를 나타내 주기 위한 Model이자 View를 나타낼 데이터를 처리하는 부분2) MVVM 동작
- Action -> View
- Command 패턴으로 View Model에 Action을 전달
- View Model은 Model에게 데이터를 요청
- Model은 View Model에게 요청받은 데이터를 응답
- View Model은 응답 받은 데이터를 가공하여 저장
- View는 View Model과 Data Binding하여 화면을 나타냄
3) MVVM 장점
- View와 Model 사이의 의존성이 없음
- View와 View Model(Command, Data Binding) 사이의 의존성이 없음
- 각각의 부분은 독립적이기 때문에 모듈화 하여 개발가능
4) MVVM 단점
- View Model의 설계가 어려움
참고
[블로그]
