iOS 아키텍처 패턴 - MVP

iOS 아키텍처 패턴 - MVP

원문 출처 : https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

 

MVP (Model, View, Presenter)

우선 기본적으로 MVC, MVP, MVVM와 같이 MV(X) 패턴들은 다음과 같이 3가지 요소로 나뉜다.

일반적인 카테고리 특징은 아래와 같고, 패턴에 따라 조금씩 차이를 보인다.

Models

- domain data 또는  데이터를 다루는 data access layer를 담당하는 카테고리.

- ‘Person’, ‘PersonDataProvider’를 떠올려 보아라.

Views

- presentation layer (GUI)를 담당하는 카테고리.

- iOS 환경에서 접두사 ‘UI’가 붙었던 모든 것을 떠올려 보라.

Controllor / Presenter / ViewModel

- Model 카테고리와 View 카테고리를 연결, 조정하는 카테고리.

- 일반적으로 뷰에서 수행된 사용자의 동작에 반응하여 모델을 변경하고, 모델의 변경 사항을 뷰로 업데이트함..

---

MVP만의 특징

Apple’s MVC의 예상에서 봤던 모습과 유사하잖아?! Apple’s MVC가 MVP야? : ㄴㄴ

 

기억을 되돌려 보면, Apple’s MVC에서는 View 카테고리가 Controller와 강하게 연관되어 있었음.

MVP의 도식도와 같기를 바랬을 뿐 현실은 그렇지 않았다.

 

- 반면에 MVP의 중재자인 ‘Presenter’는 Passive View의 life cycle과 아무런 연관이 없다. (독립성 확보!)

- 그리고 MVP의 View는 쉽게 *mocked 될 수 있으므로, Presenter에는 어떠한 layout code도 담겨있지 않다.

- Presenter는 View의 데이터와 상태를 updating 해주는 역할을 맡을 뿐이다.

 

Apple’s MVC에서 진짜로 구현하고자 했던 3가지의 독립성을 확보했다고 볼 수 있음.

 

*mocking

: unit test에서 쓰이는 핵심 기술로, 실제와 똑같은 fake 버전을 만들어 테스트하는 기술을 말한다.

예를 들어, 인터넷 요청을 받아 처리하는 코드를 작성했을 때 실제로는 인터넷을 통해서 오고가야하는데, 테스트 단계에서는 그럴 필요까진 없잖아? 속도도 느려지고.

이럴 때 실제로 네트워크를 통해서는 어떠한 요청도 수행하지 않으면서도 네트워크 동작을 정확히 제어할 수 있도록 테스트 코드에서 가짜 세션을 사용하여 테스트.

(https://www.swiftbysundell.com/posts/mocking-in-swift)

---

Apple's MVC 와 MVP의 차이점

 

* Apple’s MVC에서는 Controller가 UIViewController와 관련된 기능을 수행했다.

* MVP에서는 사실 UIViewController subclasses들은 Presenters가 아닌 Views다.

이러한 차이가 엄청난 testability를 제공한다.

다만 manual data나 event binding을 만들어야 하므로 개발 속도 비용도 따라온다.

---

[어셈블리와 관련된 중요한 정보]

MVP는 3개의 개별 layer를 가짐으로써 발생하는 어셈블리 문제를 드러내는 첫번째 패턴이다.

뷰가 모델에 대해 알기를 원하지 않기 때문에(독립성을 살리기 위함) 뷰 컨트롤러(이것이 뷰)를 presentation할 때 어셈블리를 수행하는 것은 옳지 않으므로 다른 곳에서 수행해야 한다.

예를 들어 wide Router 서비스를 제공하는 앱을 만든다고 했을 때, 어셈블리 수행과 View-to-View presentation을 다루게 된다.

이러한 문제는 MVP 뿐만아니라 뒤에 오는 다른 패턴들에도 마찬가지다.

---

좋은 아키텍처의 3가지 특징 측면에서의 평가.

- Distribution : 대부분의 책임을 Presenter와 Model이 가지고, 매우 멍청한 View를 가진다. (그냥 출력만 한다고 보면 됨)

- Testability : 최고다! 이전까지는 View와 Controller의 책임이 완전히 분리되지 않아, Model을 제외하고는 각 요소를 독립적으로 테스트 할 수 없었는데, View를 멍청하게 만들기는 했지만 책임 분리가 명확하게 되면서 각각의 요소들을 독립적으로 테스팅 할 수 있게 되었다. 따라서 대부분의 business logic도 테스트할 수 있다.

- Easy of use : 코드의 양은 MVC에 비해 많이 늘어나게 되지만, 동시에 MVP의 idea는 매우 명확해졌다.

(독립성 보장으로 각각의 요소가 어떤 역할을 하는지가 명확해짐)

 

정리 : iOS에서 MVP는 많은 양의 코드를 가지지만, 엄청난 testability를 보장한다.