안드로이드 앱 개발을 하고있는데, 디자인 패턴이란 개념없이 액티비티에 로직들을 넣고 있는 중... 문득 안드로이드 스튜디오에서도 디자인 패턴을 사용한다는게 생각났다.
아키텍쳐 디자인 패턴으로는 MVC, MVP, MVVM 대표적으로 이렇게 세 가지가 많이 쓰이는 듯 한데, 이제는 MVC는 거의 안쓰이고 MVP와 MVVM이 일반적으로 쓰이는 디자인패턴이라고 한다.
이 패턴의 공통적인 목표는 객체간의 결합도를 약하게 유지하고 다양한 이점을 취하고자 하는것이다.
그리고 위 세 가지 패턴 모두 View 와 Model 을 공통적으로 가지고 있다. 뷰는 말 그대로 사용자가 보는 화면, 입력하는 화면 등을 의미하는 느낌이고, 모델의 경우 DB 및 비즈니스 로직을 의미한다. 위 패턴은 이러한 뷰와 모델을 어떻게 연결할 것인가에 대한 대답으로 각각 컨트롤러, 프리젠터, 뷰모델이라는 이름을 해결책으로 제시하고있으며, 이 부분이 차이점이 되겠다.
MVC의 경우 컨트롤러가 뷰와 모델보다 최전방에 있기에, 사용자의 모든 접근과 행동들을 먼저 받아내게된다. 그리고 이것을 뷰와 모델에 일을 나누어주는 느낌이다. 즉, 손님도 받고 계산도 하고 서빙도 하고 직원에게 일도 시키는 그런 느낌인듯하다. 어쨋든 이렇게 한녀석이 다양한 일을 하려니, 당연히 복잡해지고 나중에 자기가 뭔 일을 하고 있는지도 알아보기 힘들겠지...
그래서 모든 일에 손을 대는 역할에서 벗어난 MVP 패턴이 생겨났다(?). 앞서 MVC패턴의 컨트롤러가 사용자의 모든 접근을 받아냈던 것에 반해, MVP패턴에서는 사용자의 접근을 받아내는 역할을 뷰라는 녀석에게 넘긴다. 이제 뷰라는 녀석은 사용자의 행동과 주문 등을 받아낸다. 하지만 뷰는 수동적인 녀석이라 프레젠터라는 녀석에게 사용자가 이런 역할을 했으니 나는 뭘해야 할까요라고 물어봐야 한다. 그리고 프레젠터는 사용자의 주문이 무엇인지 확인하고 그에 맡게 뷰에게 어떤 행동을 하라고 전달해야한다. 이때 만약 모델을 통해서 어떤 데이터 따위가 필요하다면 프레젠터는 모델에게 이를 요청하고 받아올수도 있다. 하지만 중요한건 뷰와 프레젠터의 관계인듯하다. 뷰는 수동적으로 사용자의 행동과 주문을 받아내고, 프레젠터에게 전달한다. 프레젠터는 이를 확인하고 뷰에게 명령을 내린다.
마지막으로 MVVM 패턴은 MVP패턴에서 수동적이었던 뷰의 존재를 능동적인 존재로 바꾼것이다. 이제 더이상 뷰는 수동적으로 프레젠터에게 명령을 받는 존재가아니다. 뷰는 눈치껏 프레젠터의 행동을 관찰한다. 그리고 관찰 결과에 따라 자신의 행동을 능동적으로 처리한다. 만약 프레젠터가 A에서 B로 생각을 바꿨다면, 뷰는 이 생각을 관찰하여 B라는 결과물을 만들어낸다. 이 결과로서 프레젠터는 더 이상 뷰에게 명령을 내릴 필요가 없어졌고 뷰라는 녀석을 몰라도 상관없게 됐다. 그래서 프레젠터는 단지 모델과 데이터만을 주고 받는 일만 하게된다. 이 프레젠터를 MVVM 패턴에서 뷰모델이라고 부른다.
--
나름대로 이해한 느낌을 글로 풀어 적어봤는데 아무래도 개념적인 내용으로 패턴을 이해하기에는 한계가 있어보인다. 직접 실습을 해봐야지 체감이 될듯하다...
어쨋든 가장 MVP나 MVVM을 원하는대로 사용하면 될듯하다.
근데 그냥 얼핏보기엔 MVVM 을 쓰는게 맞지않나 싶다. 아무래도 얼핏 봐도 결합도가 가장낮다. 여러 클래스가 섞이면 머리아픈게 사실이라... 그리고 애초에 안드로이드 스튜디오에는 MVVM 을 위한 라이브러리도 제공하고 있는거 보면 권장되는게 그쪽인듯싶다...
설계를 어떻게 해야할지 확 와닿지않는다는게 너무 멘붕이지만 그래도 일단.. 오늘은 여기까지