MVP(Model-View-Presenter)패턴

MVP(Model-View-Presenter)패턴 

http://tiii.tistory.com/24 및 http://www.tinmegali.com/en/model-view-presenter-android-part-1/ 자료들을 참고하여 작성하였습니다.

안드로이드는 Spring Framgwork 처럼 정형화된 패턴이 정해져 있지 않습니다. 저를 포함한 많은 개발자들이 특정한 패턴에 맞춰서 개발을 하거나 구분하지 않습니다. 계속 많은 개발자들이 안드로이드에 맞는 패턴을 찾으려 노력하고 있으며 많은 포스팅이 있습니다. 많은 포스팅 참고하여 정리할 겸 MVP관하여 정리해봄니다.

MVP란?

•           기본적으로 Model-View-Presenter 로 구분되어있다.

-       Model : View에 표시될 Data를 가공하거나 조회 등의 비즈니스 로직.

-       View : 실질적으로 화면에 보여주는 부분(Activity,Fragment,View)

-       Presenter : 전달자로서 VIew에 표시될 데이터를 Model에서 가져와 VIew에

전달

각각의 관계는 위 이미지를 보면 알 수 있습니다.(이미지출처 : http://www.tinmegali.com/en/model-view-presenter-android-part-1/)

1.    VIEW(User Action) 발생

2.    PRESENTER로 해당 이벤트 처리 메소드 호출

3.    MODEL에서 데이터 처리 및 비즈니스 로직 처리 후 PRESENTER로 전달

4.    VIEW로  전달된 데이터를 전달하여 VIEW에서 화면 갱신

MVC 패턴과 비교해보면 MVC는 VIEW는 CONTROLLER와 MODEL 존재를 다 알고 있어야 하지만 MVP의 VIEW는 MODEL의 존재를 알 필요가 없다 VIEW부분은 단순하게 화면 갱신 및 기타 UI작업만 수행해주면 된다..

 

-       저는 아직 MODEL에 대해서 어느 정도까지 구분을 해야될지가 명확하지 않아서 MODEL 부분에는 데이터가 될 VO 정도 구분하고 비즈니스 로직 부분을 PRESENTER 에서 작성하였습니다. 다른 개발자분들과 이야기해보았을 때 여러 관점이 있었으며 명확하지 않음을 느꼈습니다. 본인 취향에 맞게 Repository 패턴 쓰시는 것도 괜찮으며 제가 생각한 MVP 요점은 VIEW와 비즈니스 로직 분리와 VIEW MODEL 의 관계 끊기라고 생각하기 때문에 그 부분만 지켜준다면 무방하다고 생각합니다.

왜 MVP로 해야 하나???

•       테스트코드 작성에 용이

-       기본구조자체가 인터페이스를 사용하여 분리 및 연결을 하는 것 이기 때문에 테스트가 용이 하다고 합니다.

-       이 부분에서는 실제로 유닛테스트를 작성해보지 않아서 얼마나 이득이 있을지는 감히 잡히지 않지만 확실한 장점은 있는 것 같습니다.

•      VIEW 와 비즈니스 로직 분리로 인한 소스 분석 용이

-       지금까지 작성해오던 개발방법은 공통으로 쓰이는 통신모듈,유틸,메니저 정도 구분하여 엑티비티나 프래그먼트에 모두 작성하였습니다. 물론 소스가 짧거나 복잡하지 않을 경우에는 상관없지만 아닐 경우 UI갱신 및 생성소스와 혼합되어있어 보기 힘들게 됩니다. 이런 부분을 분리 시켜 소스분석이 용이하고 재사용에 더욱 편리하게 쓸 수 있을 것 같습니다.

 

결론

-       MVP패턴을 학습을 시작하게 된 계기가 테스트에 용이하다는 것 보다는 VIEW와 비지니스로직을 구분해서 어느정도의 소스 분리를 명확하게 할 수 있다는 것에 끌려 해보게 되었습니다. 확실히 분리하게됨으로서 얻게되는 장점들이 있는 반면 소스 분석시 따라가다보게되면 인터페이스가 나오게 되는 경우가 종종있습니다. 또한 각 화면마다 인터페이스와 프리젠터를 작성해줘야되는 번거로움이 있습니다. 이런부분을 잘 판단 하시고 작성하시면 될것 같습니다.

 

 작성 샘플코드

l  dagger2+rxjava 사용하여 작성하였습니다.

https://github.com/dunkindonass/mvpsample