Uyğun iOS Memarlığını necə seçmək olar (Hissə 2)

MVC, MVP, MVVM, VIPER və ya VIP

Birinci hissəyə burada müraciət edə bilərsiniz.

Ən vacib iOS arxitekturaları

Qisa icmal.

MVC

MVC təbəqələri aşağıdakı kimidir:

M: iş məntiqi, şəbəkə təbəqəsi və məlumatlara giriş səviyyəsi

V: UI səviyyəsi (UIKit obyektləri, storyboard, Xibs)

C: Model və görünüş arasında vasitəçiliyi əlaqələndirir.

MVC-ni anlamaq üçün onun icad olunduğu konteksti anlamalıyıq. MVC, Baxışların statusu olmayan köhnə veb inkişaf günlərində icad edilmişdir. Köhnə günlərdə brauzer veb saytdakı vizual dəyişikliyə ehtiyac duyduğumuz zaman bütün HTML-lərini yenidən yükləyir. O zaman baxış vəziyyətinin davam etdirildiyi və qurtarıldığı barədə heç bir fikir yox idi.

Məsələn, eyni HTML sənədləri, PHP və verilənlər bazası girişindən istifadə edən bəzi inkişaf etdiricilər var idi. Beləliklə, MVC-nin əsas motivasiyası görüntü səviyyəsini model səviyyəsindən ayırmaq idi. Bu, model səviyyəsinin test qabiliyyətini artırdı. İddiaya görə MVC-də görünüş və model təbəqələri bir-birlərini bilməməlidir. Bunu mümkün etmək üçün nəzarətçi adlanan bir ara qat icad edildi. Bu tətbiq olunan SRP idi.

MVC dövrünün bir nümunəsi:

  1. Görünüş səviyyəsində bir istifadəçi hərəkəti / istifadəçi hadisəsi (məs. "Yeniləmə hərəkəti") tetiklenir və bu əməliyyat nəzarətçiyə bildirilir
  2. Model səviyyəsinə məlumat göndərən nəzarətçi
  3. Qaytarılmış məlumatları nəzarətçiyə modelləşdirin
  4. Nəzarətçi görünüşün yeni məlumatlarla vəziyyətini yeniləyəcəyini söyləyir
  5. Yeniləmə vəziyyətinə baxın

Apple MVC

İOS-da, View Controller, UIKit və həyat dövrü görünüşü ilə birləşir, buna görə təmiz MVC deyil. Bununla birlikdə, MVC tərifində nəzarətçinin görünüşü və ya modelin xüsusi tətbiqini bilə bilməyəcəyini söyləyən bir şey yoxdur. Əsas məqsədi model səviyyəsinin məsuliyyətlərini baxış səviyyəsindən ayırmaqdır ki, onları yenidən istifadə edə bilək və model səviyyəsini təcrid olunmuş şəkildə sınayaq.

ViewController görünüşü ehtiva edir və modelə sahibdir. Problem ondadır ki, həm nəzarətçi kodunu, həm də görünüş kodunu ViewController-a yazırıq.

MVC tez-tez Massive View Controller problemi adlandırılan problemə səbəb olur, ancaq yalnız kifayət qədər mürəkkəbliyi olan tətbiqlərdə meydana gəlir və ciddi bir işə çevrilir.

Görünüş Denetleyicisini daha aydınlaşdırmaq üçün geliştiricinin istifadə edə biləcəyi bir neçə metod var. Bəzi nümunələr:

  • VC məntiqini cədvəl görüntüləmə metodlarının məlumat mənbəyi kimi digər siniflər üçün çıxarın və nümayəndə dizaynı nümunəsindən istifadə edərək digər sənədlər üçün səlahiyyət verin.
  • Kompozisiya məsuliyyətlərini daha aydın şəkildə bölüşdürün (məsələn, VC-nin uşaq görünüşü nəzarətlərinə bölünməsi).
  • Virtual nəzarətçidə naviqasiya məntiqinin tətbiqinə görə məsuliyyəti aradan qaldırmaq üçün koordinator dizayn modelindən istifadə edin
  • Məntiqi özündə cəmləşdirən və məlumat modelini son istifadəçiyə təqdim olunan məlumatları əks etdirən məlumat çıxışına çevirən bir DataPresenter sarğı sinifindən istifadə edin.

MVC ilə MVP

MVP-dən diaqramı gördüyünüz kimi, MVC çox oxşardır

MVC irəliyə doğru bir addım idi, amma yenə də bəzi şeylər barədə bir yoxluq və ya susqunluq ilə qeyd olundu.

Bu vaxt, Ümumdünya Şəbəkəsi böyüdü və geliştirici birliyində bir çox şey inkişaf etdi. Məsələn, proqramçılar Ajax istifadə etməyə başladılar və bir anda bütün HTML səhifəsi əvəzinə yalnız səhifələrin hissələrini yüklədilər.

MVC-də, fikrimcə, nəzarətçinin View-un xüsusi tətbiqini bilməməsinə dair bir göstərici yoxdur (yoxluq).

HTML baxış qatının bir hissəsi idi və bir çox iş bu qədər axmaq idi. Bəzi hallarda, sadəcə istifadəçidən hadisələr alır və GUI-nin vizual məzmununu göstərir.

Veb səhifələrin hissələri hissələrə yükləndiyindən, bu seqmentləşdirmə görünüş vəziyyətinin qorunmasına və təqdimat məntiqi üçün məsuliyyətlərin ayrılmasına daha çox ehtiyac yaratdı.

Təqdimat məntiqi, istifadəçi interfeysinin necə göstərildiyini və istifadəçi interfeysi elementlərinin bir-biri ilə qarşılıqlı əlaqəsini idarə edən məntiqdir. Nümunə bir yükləmə göstəricisinin nə vaxt göstərməyə / canlandırmağa başlamalı olduğunu və nə vaxt göstərməyi / canlandırmayı dayandırmağına dair idarəetmə məntiqidir.

MVP və MVVM-də baxış təbəqəsi elə məntiqsiz olmalıdır ki, onda heç bir məntiq və zəka olmasın və iOS-da baxış nəzarətçisi baxış qatının bir hissəsi olmalıdır. Görünüşün lal olması, təqdimat məntiqinin də Görünüş müstəvisindən kənarda qalması deməkdir.

MVC ilə bağlı problemlərdən biri də təqdimat məntiqinin hara getməli olduğu aydın olmamasıdır. Sadəcə bu barədə susur. Təqdimat məntiqi baxış səviyyəsində və ya model səviyyəsində olmalıdır?

Modelin rolu yalnız "xam məlumatlar" təmin etməkdirsə, bu görünüşdəki kodun belə olması deməkdir:

Aşağıdakı nümunəni nəzərdən keçirin: ad və soyadlı bir istifadəçimiz var. Görünüşdə istifadəçi adını "Soyad, Ad" (məsələn "Flores, Tiago") kimi göstərməliyik.

Modelin rolu "xam" məlumatları təmin etməkdirsə, bu görünüşdəki kodun belə olması deməkdir:

firstName = userModel.getFirstName () letName = userModel.getLastName () nameLabel.text = Soyad + “,“ + Ad

Bu o deməkdir ki, istifadəçi interfeysi məntiqini idarə etmək View-un məsuliyyətidir. Lakin bu, istifadəçi interfeysi məntiqinin vahid testini mümkünsüz edir.

Digər yanaşma, modelin yalnız göstərilməli olan məlumatları göstərməsinə imkan vermək və iş məntiqini baxışdan gizlətməkdir. Ancaq sonra həm iş məntiqi, həm də istifadəçi interfeysi məntiqi ilə işləyən modellərimiz var. Bu sınaqdan keçirilə bilən bir müəssisə olardı, lakin o zaman model dolayısı ilə görünüşdən asılıdır.

ad = userModel.getDisplayName () nameLabel.text = ad

Bu, MVP üçün aydındır və təqdimat məntiqi aparıcı səviyyəsində qalır. Bu aparıcı səviyyəsinin test qabiliyyətini artırır. İndi model və aparıcı təbəqə problemsiz sınaqdan keçirilə bilər.

Ümumiyyətlə MVP tətbiqetmələrində görünüş interfeys / protokolun arxasında gizlənir və aparıcıda UIKit-ə heç bir istinad olmamalıdır.

Diqqət çəkən başqa bir şey keçici asılılıqdır.

Denetleyicinin bir asılılıq olaraq bir iş təbəqəsi və bir asılılıq olaraq bir məlumat giriş qatına sahib olduğu təqdirdə, nəzarətçinin məlumat daxil olmaq üçün bir keçid asılılığı var. MVP tətbiqetmələrində ümumiyyətlə bütün səviyyələr arasında bir müqavilə (protokol) istifadə olunduğundan, keçid asılılığı yoxdur.

Fərqli təbəqələr də fərqli səbəblərdən və fərqli nisbətlərdə dəyişir. Beləliklə, bir səviyyə dəyişirsinizsə, bunun digər səviyyələrdə ikinci dərəcəli təsirlərə / problemlərə səbəb olacağı düşünülmür.

Protokollar siniflərdən daha sabitdir. Günlüklərdə tətbiq detalları yoxdur və müqavilələrlə əlaqələndirilmir. Beləliklə, digər səviyyələrə təsir etmədən bir səviyyə tətbiq detallarını dəyişdirmək mümkündür.

Müqavilələr (protokollar) təbəqələr arasında ayrılma yaradır.

MVP və MVVM

MVVM diaqramı

MVP ilə MVVM arasındakı əsas fərqlərdən biri də MVP-də aparıcının görünüşlə interfeys yaratması və MVVM-də görünüşün məlumat və hadisə dəyişikliyinə yönəlməsidir.

MVP-də təqdimatçı ilə interfeyslər / protokollar istifadə edərək görüntü arasında əl ilə əlaqə yaradırıq. MVVM-də RxSwift, KVO ilə avtomatik məlumat bağlama və ya ümumi və bağlanma ilə bir mexanizm həyata keçiririk.

MVVM-də ViewModel və View arasında bir müqaviləyə (məsələn, Java interfeysi / iOS protokolu) ehtiyacımız yoxdur, çünki normalda Observer Design Pattern vasitəsilə əlaqə qururuq.

MVP nümayəndə nümunəsini istifadə edir, çünki təqdimatçı qat əmrləri baxış qatına həvalə edir. Buna görə, görünüşü haqqında bir şey bilməlidir, hətta interfeys / protokol imzası olsa belə. Bildiriş Mərkəzi ilə TableView nümayəndələri arasındakı fərqi düşünün. Bildiriş Mərkəzinin rabitə kanalı yaratmaq üçün heç bir interfeysə ehtiyacı yoxdur. Bununla birlikdə, TableView Delegates, siniflərin həyata keçirməli olduğu bir protokoldan istifadə edir.

Bir yükləmə göstəricisinin təqdimat məntiqini düşünün. MVP-də aparıcı ViewProtocol.showLoadingIndicator-ı işlədir. MVVM-də, ViewModel-də bir isLoading xassəsi ola bilər. Görünüş qatında bu xüsusiyyət dəyişdikdə və özünü yenilədikdə tanımaq üçün avtomatik məlumat bağlama istifadə olunur.Təqdimatçı əmrlər verdiyi üçün MVP MVVM-dən daha cəlbedicidir.

MVVM birbaşa sifarişlərdən daha çox məlumat dəyişikliyi ilə əlaqədardır və yenilikləri görmək üçün məlumat dəyişikliklərini əlaqələndiririk. RxSwift və funksional reaktiv proqramlaşdırma paradiqmasını MVVM ilə birlikdə istifadə etdiyimiz zaman kodu daha az təsir edici və daha bəyan edici hala gətirdik.

MVVM-i test etmək MVP-dən daha asandır, çünki MVVM ayrılan şəkildə komponentlər arasında məlumat ötürən Observer Design Pattern istifadə edir. Beləliklə, görüntü ilə aparıcı arasındakı ünsiyyəti yoxlamaq üçün edilən metod çağırışlarını ələ salmaqdansa, yalnız iki obyekti müqayisə edərək məlumatdakı dəyişikliklərə baxaraq test edə bilərik.

PS: Maddənin çox böyüməsinə səbəb olan bəzi yeniləmələr etdim. Buna görə də onu üç hissəyə bölmək lazım idi. Üçüncü hissəni burada oxuya bilərsiniz.

İkinci hissə burada bitir. Bütün rəyləriniz açıqdır. Üçüncü hissə VIPER, VIP, Reaktiv Proqramlaşdırma, Ticarət, Məhdudluqlar və Kontekst Sense haqqındadır.

Oxuduğunuz üçün təşəkkür edirik! Bu məqalədən zövq aldınızsa, xahiş edirəm başqaları da oxuya bilsin deyə əl çalın