iOS 아키텍처 패턴 - Apple's MVC

iOS 아키텍처 패턴 - Apple's MVC

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

Apple's MVC (예상,바램)

우선 기본적으로 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 카테고리를 연결, 조정하는 카테고리.

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

---

Apple's MVC 만의 특징을 살펴보자.

- Controller가 중재자 역할을 잘 하고 있음. 따라서 View와 Model은 서로를 모름. (독립성!)

- Controller는 View와 Model에 의존하므로 셋 중에선 가장 재사용성이 떨어진다.

- 하지만 tricky business logic을 위한 장소도 필요하므로 이정도는 뭐 괜찮다. (이건 Model 카테고리에는 어울리지 않으므로 독립적으로 하나 필요한데, 그걸 컨트롤러가 해줌.)

 

이론상으로는 쉬워보이는데 뭔가 잘못됐음이 느껴지는가?
사람들이 MVC를 Massive View Controller의 약어라고 칭하는 것을 들어본 적이 있을 것이다. 게다가 iOS 개발자에게 View Controller offloading이 주요 토픽이 되었다. 애플에서 Classic MVC를 조금 바꾸었을 뿐인데 왜 이런 현상이 일어날까?

---

현실(Reality)

Apple's MVC (현실)

- Cocoa MVC는 controller가 View의 life cycle에 너무 많이 관여하고 있기 때문에 Massive한 View Controller를 만들도록 조장한다.

이것은 둘이 서로 독립적이라고 말하기 어렵다.

 

- Model 카테고리로 일부 business logic(데이터 처리능력)과 데이터 변환 능력을 덜어낸다 해도, 대부분의 경우에 View의 역할은 action을 Controller로 전달하는 것이므로 View의 작업을 오프로드 하는 데 선택의 여지가 별로 없다.

 

- 결국 View Controller는 는 모든 것의 대표(delegate)이자 데이터소스(data source)가 될테고, 이는 보통 네트워크 요청 및 취소와 기타 등등도 맡게 된다. (Controller만 너무 방대해지잖아!?)

 

- 당연히 View와 Controller가 긴밀하게 연관돼 있으므로, 독립적 테스트도 어렵다. (아마 Model만 테스트 가능할 걸?)

 

다만 다른 패턴들에 비해 코드 양이 적게 들고, 모두가 이 패턴에 친숙하기 때문에 경험이 적은 개발자에 의해서도 쉽게 관리 된다.

따라서 다음과 같은 경우에 Cocoa MVC 패턴을 사용한다.

• 아키텍처 연구에 많은 시간을 쓸 수 없을 때
• 작은 프로젝트라서 과한 유지비용 보수가 낭비일 경우 

정리 : Apples' MVC(= 코코아 MVC)는 개발 속도면에서 가장 우수한 아키텍처 패턴이다.