적절한 iOS 아키텍처를 선택하는 방법 (2 부)

MVC, MVP, MVVM, VIPER 또는 VIP

여기에서 1 부를 참조하십시오.

주요 iOS 아키텍처

간단한 개요.

MVC

MVC 계층은 다음과 같습니다.

M : 비즈니스 로직, 네트워크 계층 및 데이터 액세스 계층

V : UI 계층 (UIKit 사물, 스토리 보드, Xibs)

C : 모델과 뷰 사이의 조정을 조정합니다.

MVC를 이해하려면 MVC가 발명 된 맥락을 이해해야합니다. MVC는 뷰가 상태가없는 이전 웹 개발 시대에 발명되었습니다. 예전에는 웹 사이트를 시각적으로 변경해야 할 때마다 브라우저가 전체 HTML을 다시로드합니다. 당시에는 뷰 상태가 유지되고 저장되는 개념이 없었습니다.

예를 들어 동일한 HTML 파일, PHP 및 데이터베이스 액세스 내에 혼합 된 일부 개발자가있었습니다. 따라서 MVC의 주요 동기는 뷰 레이어를 모델 레이어에서 분리하는 것이 었습니다. 이는 모델 레이어의 테스트 가능성을 높였습니다. MVC에서 View와 Model 레이어는 서로에 대해 아무것도 몰라 야합니다. 이를 가능하게하기 위해 Controller라는 중개 계층이 발명되었습니다. 이것이 적용된 SRP였습니다.

MVC주기의 예 :

  1. 뷰 레이어의 사용자 작업 / 이벤트 (예 : 작업 새로 고침)가 시작되고 해당 작업이 컨트롤러에 전달됩니다.
  2. 모델 레이어에 데이터를 요청하는 컨트롤러
  3. 반환 데이터를 컨트롤러로 모델링
  4. 컨트롤러는 View가 새 데이터로 상태를 업데이트한다고 말합니다.
  5. 상태 업데이트보기

애플 MVC

iOS에서 View Controller는 UIKit 및 수명주기보기에 연결되므로 순수한 MVC가 아닙니다. 그러나 MVC 정의에서 Controller가 View 또는 Model 특정 구현을 알 수 없다는 말은 없습니다. 그의 주요 목적은 모델 레이어를 뷰 레이어와 분리하여 재사용하고 모델 레이어를 격리하여 테스트하는 것입니다.

ViewController는 View를 포함하고 Model을 소유합니다. 문제는 컨트롤러 코드와 ViewController의 뷰 코드를 작성하는 데 사용되었습니다.

MVC는 종종 Massive View Controller라는 문제를 발생 시키지만, 이는 단지 복잡성이 충분한 앱에서만 발생하고 심각한 문제가됩니다.

개발자가 View Controller를보다 관리하기 쉽게 만드는 데 사용할 수있는 몇 가지 방법이 있습니다. 몇 가지 예 :

  • 델리게이트 디자인 패턴을 사용하여 테이블 뷰 메소드 데이터 소스와 같은 다른 클래스의 VC 로직 추출 및 다른 파일의 델리게이트 추출
  • 컴포지션을 사용하여 책임을보다 명확하게 분리하십시오 (예 : VC를 하위 뷰 컨트롤러로 분할).
  • 코디네이터 디자인 패턴을 사용하여 VC에서 탐색 논리를 구현할 책임을 제거하십시오.
  • 논리를 캡슐화하고 데이터 모델을 최종 사용자에게 제공되는 데이터를 나타내는 데이터 출력으로 변환하는 DataPresenter 랩퍼 클래스를 사용하십시오.

MVC와 MVP

MVP 다이어그램은 MVC와 매우 유사합니다.

MVC는 한 단계 발전했지만 여전히 몇 가지 사항에 대한 부재 또는 침묵으로 표시되었습니다.

한편, 월드 와이드 웹이 커지고 개발자 커뮤니티의 많은 것들이 진화했습니다. 예를 들어, 프로그래머는 Ajax를 사용하기 시작했으며 전체 HTML 페이지 대신 페이지의 일부만 한 번에로드합니다.

MVC에서는 Controller가 View (absence)의 특정 구현을 알 수 없다는 것을 나타내는 것은 아무것도 없다고 생각합니다.

HTML은 View 레이어의 일부였으며 많은 경우에 멍청했습니다. 경우에 따라 사용자로부터 이벤트 만 수신하고 GUI의 시각적 컨텐츠를 표시합니다.

웹 페이지의 일부가 파트로로드되기 시작함에 따라,이 세분화는 View 상태를 유지하는 방향으로 나아가고 프리젠 테이션 로직 책임 분리의 필요성이 커졌습니다.

프리젠 테이션 로직은 UI를 표시하는 방법과 UI 요소가 상호 작용하는 방식을 제어하는 ​​로직입니다. 예를 들어 로딩 표시기가 표시 / 애니메이션을 시작해야하는 시점과 표시 / 애니메이션을 중지해야하는 시점의 제어 논리가 있습니다.

MVP 및 MVVM에서 View Layer는 논리 나 인텔리전스없이 멍청해야하고 iOS에서는 View Controller가 View Layer의 일부 여야합니다. 뷰가 멍청하다는 사실은 프리젠 테이션 로직조차도 뷰 레이어에서 벗어나는 것을 의미합니다.

MVC의 문제점 중 하나는 프리젠 테이션 로직이 어디에 있어야하는지 명확하지 않다는 것입니다. 그는 단순히 그것에 대해 침묵합니다. 프리젠 테이션 로직이 뷰 레이어 또는 모델 레이어에 있어야합니까?

모델의 역할이 "원시"데이터를 제공하는 것이라면보기의 코드는 다음과 같습니다.

다음 예를 고려하십시오. 이름과 성을 가진 사용자가 있습니다. 보기에서 사용자 이름을 "성, 이름"(예 : "Flores, Tiago")으로 표시해야합니다.

모델의 역할이 "원시"데이터를 제공하는 경우 뷰의 코드는 다음과 같습니다.

firstName = userModel.getFirstName ()하자
let lastName = userModel.getLastName ()
nameLabel.text = 성 + ","+ 성

따라서 UI 로직을 처리하는 것은 View의 책임입니다. 그러나 이로 인해 UI 로직이 단위 테스트가 불가능합니다.

다른 접근 방식은 모델이 표시해야하는 데이터 만 표시하도록하여 뷰에서 비즈니스 논리를 숨기는 것입니다. 그러나 비즈니스와 UI 로직을 모두 처리하는 모델로 끝납니다. 단위 테스트 가능하지만 모델은 암시 적으로보기에 의존하여 종료됩니다.

let name = userModel.getDisplayName ()
nameLabel.text = 이름

MVP는 그것에 대해 명확하고 프리젠 테이션 로직은 Presenter Layer에 유지됩니다. 이를 통해 Presenter 레이어의 테스트 가능성이 높아집니다. 이제 Model 및 Presenter Layer를 쉽게 테스트 할 수 있습니다.

일반적으로 MVP 구현에서보기는 인터페이스 / 프로토콜 뒤에 숨겨져 있으며 Presenter에는 UIKit에 대한 참조가 없어야합니다.

명심해야 할 또 다른 사항은 전이 의존성입니다.

컨트롤러에 비즈니스 계층이 종속성으로 있고 비즈니스 계층에 데이터 액세스 계층이 종속성으로 있으면 컨트롤러에 데이터 액세스 계층에 대한 전이 종속성이 있습니다. MVP 구현은 일반적으로 모든 계층간에 계약 (프로토콜)을 사용하므로 전 이적 종속성이 없습니다.

다른 계층은 다른 이유로 그리고 다른 속도로 변경됩니다. 따라서 레이어를 변경할 때 다른 레이어에서 2 차 효과 / 문제가 발생하지 않도록해야합니다.

프로토콜은 클래스보다 안정적입니다. 프로토콜은 구현 세부 사항과 계약에 따라 구현되지 않았으므로 다른 계층에 영향을주지 않고 계층의 구현 세부 사항을 변경할 수 있습니다.

따라서 계약 (프로토콜)은 레이어간에 디커플링을 만듭니다.

MVP vs MVVM

MVVM 다이어그램

MVP와 MVVM의 주요 차이점 중 하나는 MVP에서 Presenter가 인터페이스를 통해 View와 통신하고 MVVM에서 View가 데이터 및 이벤트 변경을 지향한다는 것입니다.

MVP에서는 인터페이스 / 프로토콜을 사용하여 Presenter와 View를 수동으로 바인딩합니다.
MVVM에서는 RxSwift, KVO와 같은 것을 사용하여 자동 데이터 바인딩을 만들거나 제네릭과 클로저가있는 메커니즘을 사용합니다.

MVVM에서는 일반적으로 Observer 디자인 패턴을 통해 통신하기 때문에 ViewModel과 View 간의 계약 (예 : Java 인터페이스 / iOS 프로토콜)이 필요하지 않습니다.

발표자 레이어는 주문을보기 레이어에 위임하기 때문에 MVP는 위임 패턴을 사용하므로 인터페이스 / 프로토콜 서명 일지라도보기에 대해 알아야합니다. Notification Center와 TableView 대리인의 차이점을 생각해보십시오. 알림 센터에는 통신 채널을 만들기위한 인터페이스가 필요하지 않지만 TableView 대의원은 클래스가 구현해야하는 프로토콜을 사용합니다.

로딩 표시기의 프리젠 테이션 로직을 생각하십시오. MVP에서 발표자는 ViewProtocol.showLoadingIndicator를 수행합니다. MVVM에서는 ViewModel에 isLoading 속성이있을 수 있습니다. 자동 데이터 바인딩을 통한 뷰 레이어는이 속성이 변경되고 새로 고쳐지는시기를 감지합니다. 발표자가 명령을 내리기 때문에 MVP는 MVVM보다 더 중요합니다.

MVVM은 직접 주문보다 데이터 변경에 대한 것이므로 데이터 변경과 업데이트보기를 연결합니다. MVVM과 함께 RxSwift 및 기능적 리 액티브 프로그래밍 패러다임을 사용하면 코드의 필요성이 줄어들고 선언적입니다.

MVVM은 분리 된 방식으로 구성 요소간에 데이터를 전송하는 관찰자 디자인 패턴을 사용하므로 MVP보다 테스트하기가 더 쉽습니다.
따라서 View와 Presenter 간의 통신을 테스트하기 위해 호출하는 메서드를 모의하는 것보다는 두 개체를 비교하는 것만으로 데이터의 변경 사항을 살펴 보는 것만으로 테스트 할 수 있습니다.

추신 : 나는 기사가 많이 자라도록 업데이트 했으므로 세 부분으로 나눌 필요가있었습니다. 여기서 3 부를 읽을 수 있습니다.

두 번째 부분은 여기서 끝납니다. 모든 의견을 환영합니다. 3 부에서는 VIPER, VIP, 반응 형 프로그래밍, 트레이드 오프, 제약 조건 및 상황 감지에 대해 설명합니다.

읽어 주셔서 감사합니다! 이 기사가 마음에 드 셨다면 박수를 치십시오
그래서 다른 사람들도 읽을 수 있습니다 :)