내가 주로 사용하는 패턴은 mvc, mvvm인데 사실 이것도 제대로 이해하고 사용하는 편은 아니다.
그래도 새로운 개념을 배울때 목적을 알고 하면 이해하기 쉬워서 mvp의 목적에 대해 먼저 찾아보니
MVP란?
model - view - presenter로
mvp가 나오게 된 이유는 view와 model을 완전히 분리해서 사용하기 위함이다.
mvp는 model의 역할인 비즈니스 로직을 독립적으로 테스트할 수 있게된다.
뷰
뷰에 직접 접근해서 ui요소를 다룬다. 근데 추가로 뷰에서 발생하는 이벤트들에 대한 핸들링이 필요한데. presenter에 위임하는 것이 mvp패턴이다.
그래서 뷰(view, viewcontroller)가 presenter를 소유한다.
그리고 사용자 입력이나, 이벤트가 발생하면 presenter를 호출하여 presenter가 처리한다.
프레젠터
뷰와 모델 사이에서 자료 전달 역할을 함.
즉 프레젠터는 모델, 뷰에 대한 프로퍼티를 소유하고
모델을 기반으로 뷰를 업데이트 하는 로직을 수행한다.
모델
앱 데이터 및 상태를 소유하고 비지니스 로직을 수행한다.
전부터 그냥 패턴과 관련해서 모델의 역할에 대해 좀 햇갈렸는데, 그 이유가 모델을 구현하는 것과 사용하는 방법을 다르게 생각해야 하는데 혼동했었다.
앱의 비지니스 로직을 수행하기 위해 코드와 상태에 대한 코드를 작성하는 것인데, 즉 달리 말하면 앱 상태를 변수에 저장하고, 비지니스 로직을 수행할 메소드들을 구현하면 된다.
그리고 모델의 소유는 다른 비지니스 로직 수행과 코드 상태와 별개의 문제인 것으로 주로 뷰와 모델을 중재하는 프레젠터나 뷰모델, 뷰컨트롤러가 소유하는거 같다.
디자인 패턴에 대해 처음보다 글을 봐도 이해하기 수월해졌는데, 처음에 이해가 어려웠던 이유가 내 생각에는 직접 구현해보지 않아서 그런거 같다.
구현해보고 보니 뷰,모델,뷰컨트롤러,뷰모델등 각각을 누가 소유할지에 대해서도 고민해 보게 되고
각각의 안에 어떤 프로퍼티를 갖을지 (윗줄과 같은 소유관계)에 대해 고민하게 되고
서로의 관계를 고려한 어떤 메소드를 구현해야 할지의 고민을 해보니
서로의 관계를 연결해주는 것과 서로의 소유관계에 대해 이해가 좀 높아지는거 같다.
참고 블로그