[Android] MVC, MVP 아키텍처

https://developer.android.com/

 

이전 포스팅에서는 안드로이드 공식 문서의 아키텍처 가이드를 살펴보았다.

[Android/Jetpack] 앱 아키텍처 가이드(App Architecture Guide)

해당 문서는 안드로이드에서 권장하고 있는 MVVM 아키텍처에 관련된 내용이었다. 오늘은 MVVM 이전 아키텍처에 대해 좀 더 자세한 내용을 알아보자! 앞으로 앱 개발을 할 때 더욱 효율적이고, 유지보수가 편리한 코드로 개발하기 위해 아키텍처에 대한 이해가 높아야 한다고 생각한다. 

 

 

안드로이드의 아키텍처는 MVC, MVP, MVVM의 순서로 발전을 거쳐왔음

MVC 아키텍처 

• Model : 데이터 로직 담당 (데이터 처리)
• View : 사용자의 화면 담당 (UI 처리)
• Controller : 비즈니스 로직 담당 (사용자 이벤트 처리)

1. Controller가 사용자 이벤트를 감지한다.
2. Controller는 사용자 이벤트에 따른 데이터 업데이트가 필요한지 확인한다.
3. 데이터 업데이트가 필요한 경우, Model이 데이터 업데이트를 처리한다.
4. Model은 View에게 자신이 업데이트 되었다는 사실을 알린다. 
5. View는 Model이 업데이트 되었는지 확인한다.
6. Model이 업데이트가 된 경우, View는 업데이트된 데이터를 모델에서 가져오고, 이를 바탕으로 UI를 업데이트한다.

Web에서 적용되는 MVC 패턴은 View와 Control이 모두 분리된 상태이지만,

안드로이드는 Activity/Fragment가 View와 Control의 역할을 동시에 수행한다.

[ 장점 ] 

• 개발기간이 짧아질 수 있음 (안드로이드에서의 장점 → UI 클래스에서 모든 것을 잘 동작하게 한다면)
• 구현이 쉽고, 코드를 파악하는 것이 어렵지 않음
• Model의 비종속성으로 재사용이 가능함
• 유닛테스트에서 View는 테스트할 부분이 없기 때문에 Model만 테스트 가능함

[ 단점 ]

• Model과 View 사이에 의존성 발생 → View에서 Model을 직접 참조하게 되어 앱이 커지고 유지보수가 힘듦
• 스파게티 코드가 될 가능성이 높음 → 함수, 클래스 분리가 적절하게 이루어지지 않은 확률이 높아짐
• 시간이 지날수록 Controller에 많은 코드가 쌓여 코드 비대화로 문제 발생 가능
• 유닛테스트가 어려움 → 대부분의 처리가 UI에서 이루어지므로 UI 위주의 테스트 코드를 작성해야 함

 

MVP 아키텍처

• Model : 내부적으로 사용하는 데이터를 저장/처리하는 역할
• View : 화면에서 발생하는 이벤트를 감지하고, UI 처리를 Presenter에게 요청
• Presenter : View로부터 요청받은 이벤트를 처리하고 처리한 결과를 View에게 전달

1. View에서 사용자 이벤트를 감지한다.
2. View가 Presenter에게 이벤트 처리 요청을 한다.
3. Presenter는 Model에게 View가 요청한 이벤트 처리에 필요한 데이터를 요청한다.
4. Model은 로컬/서버로부터 데이터를 가져온다.
5. Model은 가져온 데이터를 Presenter에게 전달한다.
6. Presenter는 View에게 이벤트 처리 결과를 전달한다.
7. View는 Presenter로부터 전달받은 결과로 UI를 업데이트한다.

MVC와의 차이

MVC와는 다르게 UI(View)와 비즈니스 로직(Model)을 분리하고,

서로 간에 상호작용을 다른 객체(Presenter)에 그 역할을 줌으로써 서로의 영향(의존성)을 최소화한다.

• Activity와 Fragment는 View의 일부로 간주됨 → View는 유저 이벤트를 Presenter로 전달하는 역할을 함
• Presenter는 Controller와 Model과 View의 매개체라는 점에서 유사하지만, View에 직접 연결되는 대신 인터페이스를 통해 상호작용을 한다는 점에서 차이가 있다.
  • 인터페이스를 통해 작용하므로 MVC가 가진 테스트 문제와 모듈화/유연성 문제 또한 해결할 수 있다.
  • View에게 표시할 방법을 지시하지 않고 단순히 UI에 표시할 데이터만 View에게 전달하게 됨

 

[ 장점 ]

• Model과 View를 분리시켜 결합을 없앨 수 있음 (Model 관련 처리들은 Presenter를 통해 이루어지기 때문)
• MVP 각 역할에 대한 추상화가 가능하고 이를 통해 분리가 깔끔하게 이루어질 수 있음 (한 클래스의 코드가 방대해지는 것을 막음)

[ 단점 ]

• Presenter와 View는 1:1 관계를 가져야 하므로 둘의 결합도가 높아짐

 

---

reference >

• http://blog.dramancompany.com/2016/08/%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C%EC%97%90-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EB%8F%84%EC%9E%85%ED%95%98%EA%B8%B0/
• https://thdev.tech/androiddev/2016/10/23/Android-MVC-Architecture/
• https://velog.io/@jojo_devstory/%EC%95%88%EB%93%9C%EB%A1%9C%EC%9D%B4%EB%93%9C-%EC%95%84%ED%82%A4%ED%85%8D%EC%B3%90-%ED%8C%A8%ED%84%B4-MVC%EA%B0%80-%EB%AD%98%EA%B9%8C