MVP 대 MVC 대 MVVM 대 VIPER. iOS 개발에 더 나은 것은 무엇입니까?

모든 집에 견고한 지하실이 있는 것처럼 모든 소프트웨어 프로젝트에는 기반이 되는 소프트웨어 아키텍처가 있으며 각 프로젝트에는 고유한 앱 구조가 있습니다. 아키텍처 패턴의 유형은 다를 수 있지만 가장 일반적으로 사용되는 4가지 패턴이 있습니다. 전체 IT 세계가 지속적으로 비판하지만 동시에 계속 사용하는 MVC, MVP, MVVM 및 Viper (마지막 하나는 iOS 아키텍처 패턴으로 대부분) . 이러한 패턴을 비교하고 Swift로 작성된 각 프로젝트의 경우에 더 적합한 것을 선택하는 방법은 이 기사에서 더 자세히 알아볼 것입니다.

사물의 시간적 순서에 따라 첫 번째 소프트웨어 디자인 패턴이 나타나면 이러한 ios 개발 아키텍처 패턴의 일반적인 문제가 도착하는 데 오래 걸리지 않았습니다.

예를 들어, 서버-클라이언트 통신의 문제 - 서로 어떻게 상호 작용합니까? 또는 다른 것 - 애플리케이션의 비즈니스 로직을 인앱 로직과 분리하는 문제; 애플리케이션 아키텍처 측면에서 이것이 어떻게 수행되어야 합니까? 그들로 인해 다른 아키텍처 계층에 대한 다양한 디자인 패턴이 세계를 보았습니다. 그 중 가장 잘 알려진 것은 다음과 같습니다.

- 싱글톤 디자인 패턴.

이 패턴은 하나의 클래스가 하나의 객체에만 적용될 수 있도록 하며, 이 옵션은 제한된 양의 인스턴스(또는 하나의 인스턴스만)가 시스템에서 승인될 때 사용됩니다.

- 데코레이터 디자인 패턴.

싱글톤과 대조적으로 이 패턴(어댑터 패턴과 함께 래퍼라고도 함)을 사용하면 특정 동작을 단일 개체(정적으로 또는 동적으로)에 추가할 수 있으며 이 모든 것이 다른 개체의 동작에 영향을 주지 않고 하나는 클래스를 공유합니다.

- 브리지 디자인 패턴.

"Design Patterns"라는 책의 저자인 악명 높은 Gang of Four가 처음 소개한 이 아키텍처 패턴은 "캡슐화, 집계를 사용하고 상속을 사용하여 책임을 다른 클래스로 분리할 수 있습니다. 클래스가 자주 있을 때 객체 지향의 기능 프로그래밍은 프로그램에 대한 최소한의 사전 지식으로 프로그램 코드를 쉽게 변경할 수 있기 때문에 매우 유용합니다. [출처: 위키]

이러한 패턴은 상당히 다르지만 각각의 코드 작성자에게 공통적인 문제가 발생했습니다. 예를 들어, Singleton의 "massivity"가 있습니다. 싱글톤은 너무 전역적입니다. 코드의 종속성이 인터페이스에 노출되는 대신 애플리케이션 내부에 깊숙이 숨겨져 있기 때문입니다. 이것이 소프트웨어 개발 과정에서 새로운 패턴이 끊임없이 나타나는 이유입니다.

가장 일반적으로 사용되는 4가지 패턴은 MVC, MVP, MVVM 및 VIPER (주로 iOS의 경우)입니다.

나열된 것과 같은 순서로 개발되었으며 모두 고유한 장점과 결함이 있어 각각을 어디에 적용해야 하는지에 대해 수많은 분쟁이 발생합니다. 그들이 구현하는 모범 사례에 조금 더 주의를 기울이면 상황이 조금 해결될 수 있습니다.

MVC 패턴

1970년대 초 노르웨이의 컴퓨터 과학자 Trygve Reenskaug, Module - View - Controller에 의해 처음 소개된 모든 소프트웨어 패턴의 조상은 MVC로 널리 알려진 객체 지향 프로그래밍의 첫 번째 패턴 접근 방식 중 하나입니다.

View 부분은 시스템 사용자(모바일 또는 웹 앱의 인터페이스 등)에 대한 모든 것을 표시하는 역할을 합니다. 모델은 일반적으로 데이터베이스, 비즈니스 엔터티 및 나머지 데이터를 담당합니다. 차례로 Controller는 Model의 작업, 데이터베이스에 제공된 데이터, 언급된 데이터베이스에서 View 부분으로 또는 그 반대로 표시를 규제합니다.

MVC 모델이 보편적이더라도 가장 큰 두 경쟁자인 Apple과 Google에는 Model - View - Controller 시스템을 나타내는 고유한 패턴이 있습니다. Apple 시스템이 가지고 있는 문제는 View와 Controller 부분 간의 긴밀한 연결, View와 Controller를 거의 하나로 통합하고 Model 부분을 분리한 상태로 두는 데 있습니다.

결과적으로 테스트 프로세스가 좋지 않게 됩니다. 모델만 검사할 수 있고 V&C(밀접한 연결로 인해)는 전혀 테스트할 수 없습니다.

컨트롤러와 뷰 세그먼트 간의 강력한 연결은 소프트웨어와 관련하여 진정으로 "불건전한" 것으로 판명되었으므로 곧 새로운 패턴이 세상에 나타났습니다.

MVP 패턴.

우리 중 많은 사람들이 최소 실행 가능 제품(Minimum Viable Product)의 맥락에서 이 지름길을 들었지만 소프트웨어 엔지니어링 측면에서는 다른 의미입니다. Model View Presenter 패턴에는 핵심 포인트가 거의 없으며 MVC와 큰 격차를 형성합니다.

MVP 모델

• 보기는 모델에 더 느슨하게 결합됩니다. Presenter는 Model을 View에 바인딩할 책임이 있습니다.

• 보기와의 상호 작용이 인터페이스를 통해 이루어지기 때문에 단위 테스트가 더 쉽습니다.

• 일반적으로 발표자 보기 = 일대일 매핑. 복잡한 보기에는 여러 발표자가 있을 수 있습니다.

MVC 패턴

• 컨트롤러는 동작을 기반으로 하며 뷰 간에 공유할 수 있습니다.

• 표시할 보기를 결정하는 역할을 할 수 있습니다.
  [출처: 인프라지스틱스]

이 배열에서 모델의 기능은 동일하게 유지됩니다. Presenter는 각각 비즈니스 로직을 담당합니다. V 부분은 특히 관심을 끄는 부분입니다. 상호 작용 권한이 있는 View와 View Controller의 두 부분으로 나뉩니다. MVVM 대 MVC 질문이 있을 때 이 유형의 시스템은 MVC 패턴에서 사용되는 "과도한 중독" 보기 및 컨트롤러 모드 문제를 해결합니다.

이 경우 모델, 사용자 상호 작용이 있는 보기 및 발표자 부분과 같은 테스트 장애물도 해결됩니다. 이 모든 항목을 테스트할 수 있습니다.
아직 존재하는 불편함은 Presenter의 몫입니다. 그러나 너무 방대하지만 기존의 모든 비즈니스 로직을 고려합니다. 이것이 바로 다음 행위가 시작된 이유입니다.

MVVM 패턴

Model-View-ViewModel 소프트웨어 아키텍처 패턴은 2005년 Microsoft의 설계자 중 한 명인 John Gossman이 만들었습니다. MVVM 모델의 세 가지 핵심 구성 요소는 각각 다음과 같습니다.
모델은 "비즈니스 및 유효성 검사 논리와 함께 데이터 모델을 포함하는 응용 프로그램 도메인 모델의 구현입니다. 모델 개체의 예로는 리포지토리, 비즈니스 개체, DTO(데이터 전송 개체), POCO(Plain Old CLR Objects), 생성된 엔터티 및 프록시 개체가 있습니다. [출처: 마이크로소프트]

보기는 다시 사용자가 볼 수 있는 모든 것입니다. 레이아웃, 구조 및 화면에 있는 모든 것의 모양입니다. 기본적으로 응용 프로그램 내에서 응용 프로그램의 페이지가 됩니다. View는 이 부분과 Model 자체 간의 모든 통신을 제외하고 ViewModel에만 업데이트를 가져오고 보냅니다.

ViewModel은 View와 Model 시스템 구성 요소 사이의 "상호 연결 체인"으로 간주되며 주요 기능은 View의 논리를 처리하는 것입니다. 일반적으로 뷰 모델은 모델 클래스의 메서드를 호출하여 모델과 상호 작용합니다. 그런 다음 보기 모델은 Microsoft에서 설명한 대로 보기에서 쉽게 사용할 수 있는 형식으로 모델의 데이터를 제공합니다.

MVC와 iOS MVVM의 주요 차이점은 MVVM의 배포 패턴이 이전에 나열된 MVC보다 낫지 만 MVP와 비교할 때 엄청나게 오버로드된다는 것입니다. 여기에서 테스트는 특히 중요한 문제입니다. 코드를 명확하게 작성하는 동안 전체 프로젝트가 제대로 작동한다는 것을 보장할 수 없기 때문입니다.

차세대 아키텍처 패턴의 진화는 최근에 발표되었으며 이제 가장 신선한 소프트웨어 아키텍처 접근 방식입니다.

iOS VIPER 아키텍처

제공할 최고의 아키텍처 솔루션을 찾던 전 세계의 iOS 개발자는 전 세계 소프트웨어 전문가를 위한 교육 세션을 제공하는 잘 알려진 플랫폼인 Clean Coders에서 Uncle Bob이 도입한 소위 "클린 아키텍처" 접근 방식에 부딪쳤습니다.

Clean Architecture는 애플리케이션의 논리적 구조를 여러 책임 수준으로 분할합니다. 결국 이 "분리"는 긴밀한 종속성 문제를 해결하고 모든 수준의 테스트 가용성을 높입니다.

ios 개발을 위한 VIPER

VIPER는 iOS 빌드 애플리케이션을 위한 Clean Architecture의 구현입니다. 모든 패턴의 이름에 대한 공통 규칙으로서 View, Interactor, Presenter, Entity 및 Routing에 대해서도 백워드입니다. VIPER의 각 부분은 특정 요소, 특히 다음을 담당합니다.

1. View는 사용자가 인터페이스로 수행하는 작업을 미러링하는 역할을 합니다.

2. VIPER 패턴 내에서 Presenter의 책임은 상당히 제한적입니다. Entity에서 업데이트를 수신하지만 데이터를 보내지는 않습니다.

3. Interactor는 실제로 Entities에 해당하는 시스템의 일부입니다. 이 체계는 다음과 같은 방향으로 작동합니다. Presenter는 Interactor에게 View 모델의 변경 사항을 알리고 Interactor는 Entity 부분에 연결하고 Entity Interactor에서 수신한 데이터와 함께 Presenter로 돌아갑니다. 모든 데이터 모델, 모든 엔터티 및 모든 웹 사이트는 Interactor 부분에 연결됩니다.

4. 엔티티는 Interactor에 의해 제어되는 개체(제목, 콘텐츠 등)로 구성됩니다. I-part를 통해서만 Presenter와 직접 상호 작용하지 않습니다.

5. 라우팅(또는 와이어프레임이라고도 함)은 모든 화면 간의 탐색을 담당하며 기본적으로 라우팅을 담당합니다. Wireframe은 UIWindow, UINavigationController 등의 개체를 제어합니다.

특히 iOS 아키텍처 시스템 내에서는 Apple MVC의 모든 구성 요소를 포함하지만 이전에 코더를 미치게 만들던 긴밀한 연결이 없는 UIkit이라는 프레임워크를 기반으로 구축되었습니다.

VIPER 모듈은 훌륭한 패턴의 배포를 통해 사용 가능한 모든 기능을 테스트할 수 있으므로 단위 테스트와 관련하여 유용합니다. 여러 면에서 이것이 개발자가 이전 MVC, MVP 및 MVVM 소프트웨어 패턴에서 직면한 주요 어려움이었습니다.

모든 것을 왕관하기 위해.

이 4가지 소프트웨어 디자인 패턴은 모두 iOS 개발을 위한 최고의 아키텍처 패턴 중 하나로 종종 불립니다. 비록 모두 이상적이지 않고 개발할 모든 프로젝트에 보편적으로 사용되지는 않지만. 우울한 면에서 각 패턴이 가지고 있는 문제의 짧은 목록은 다음과 같습니다.

• MVC, MVP, MVVM - 모두 이 "밀접한 연결" 문제가 있어 개발 업데이트를 도입하고 나중에 테스트를 수행하는 것이 상당히 힘든 작업입니다.

• VIPER 대 MVVM, MVC 또는 MVP 는 승리한 경우로 생각됩니다. 높은 유연성과 뛰어난 테스트 가능성에도 불구하고 생성하기 어려운 많은 뉘앙스가 있습니다.

100% 고체 솔루션이 있습니까? 실제로는 아니지만 각 프로젝트에 대해 이 4가지 iOS 앱 패턴 중 하나가 필요한 것일 수 있습니다. 그리고 그렇지 않다면 둘의 혼합물이 될 것입니다. 아니면 3개일 수도 있습니다. 운세는 대담한 것을 선호한다고 하는데, 대담하게 소프트웨어 디자인 패턴을 가지고 놀지 않겠습니까?

Max Mashkov와 Elina Bessarabova가 작성했습니다.