애플리케이션의 규모 커지며 유지보수성을 높이려고 디자인 패턴들이 등장
그 중 MVC,MVP에 대해 알아보겠습니다.
두 패턴에 Model & View는 공통으로 존재
- View: 사용자가 보게되는 화면인 UI
ex) Activity, Fragment…
- Model: 데이터를 처리하는 역할
ex) dataClass, Repository…
MVC 패턴
Model - View - Controller
세 가지 측면으로 관심사 분리
Controller
컨트롤러는 View로부터 사용자에게 입력을 받거나 이벤트가 발생하면 로직에 맞게 Model 변경
Model에서 데이터가 변화되는 것에 따라 컨트롤러는 View의 상태를 적절하게 업데이트
MVC패턴에서는 액티비티와 프래그먼트가 View의 역할도 하면서 컨트롤러 역할도 한다!
→ 만능이네 개좋은데? 가 아니라 분리성이 떨어져요..ㅠ
장점
- Model에서 데이터를 가져와 View에 표현하고 컨트롤러를 통해 이벤트가 발생하면 Model과 View를 갱신 → 구조가 직관적이고 단순하다!
- 단순한 구조로 인해 볼륨이 작은 앱을 개발할때 빠르게 진행시킬 수 있다
단점
- 하지만 구조가 단순한 만큼 액티비티와 프래그먼트가 뚱뚱해진다
- 스파게티 코드가 될 확률이 높아 규모가 큰 앱에서는 가독성과 유지보수성이 떨어질 수 있음
- 특정 View와 Model에 의존적이라 결합도가 높다
→ 유닛테스트 거의 불가능 (힝구..)
- Mockito라는 프레임워크를 이용하면 유닛테스트가 가능할 것 같다는 글도 있는데 Mockito는 뭘까요…
( 모르는게 너무 많아!!)
MVP 패턴
Model - View - Presenter
세 가지 측면으로 관심사 분리
MVP에서의 액티비티, 프래그먼트는 컨트롤러 역할은 하지 않고 View의 역할만 한다
Presenter
View 와 Model 을 연결해주는 역할, Presenter로 인해 UI 로직과 비지니스 로직을 분리할 수 있음
Presenter 내부에 Model과 View의 인스턴스를 가지며 이 둘을 연결해주는 역할을 하므로 View와 Presenter는 1:1 관계임
장점
- MVC는 View(액티비티,프래그먼트)에서 Model을 직접 생성하고 변경하기에 의존적이었지만 MVP는 Presenter로 인해 둘을 분리하여 결합도를 낮춤
- UI로직은 → View , 비지니스 로직 → Model 로 분리하고 Presenter가 연결 역할을 해주어 유닛테스트가 수월해짐
단점
- View에서 Presenter를 직접 생성하기에 의존성이 높고 1:1 관계를 유지해야 해서 View가 많아지면 Presenter도 많아짐
- View와 Model은 연결시켜주는 역할이 Presenter이기에 앱에 기능이 추가될 때마다 Presenter의 코드 양이 많아짐 (돼지네!!)
[참고 velog]
KU CSE