MVP vs MVC vs MVVM vs VIPER. iOS Geliştirme için Daha İyi Nedir?

Her evin sağlam bir bodrum katı olduğu gibi, her yazılım projesinin üzerine kurulu bir yazılım mimarisi ve her projenin kendi uygulama yapısı vardır. Mimari kalıp türleri değişebilir, ancak en sık kullanılan 4 tane vardır - tüm BT dünyasının sürekli eleştirdiği ancak aynı zamanda kullanmaya devam ettiği: MVC, MVP, MVVM ve Viper (en sonuncusu çoğunlukla iOS mimari kalıbı olarak) . Bu kalıpların karşılaştırılması ve Swift tarafından yazılan her bir projenin durumu için daha uygun olanı seçmek, bu makalenin ilerleyen bölümlerinde keşfedilecektir.

Kronolojik sırayı takip ederek, ilk yazılım tasarım kalıpları ortaya çıktıktan sonra, bu ios geliştirme mimarisi kalıplarının ortak sorunlarının ortaya çıkması uzun sürmedi.

Örneğin, sunucu-istemci iletişimi sorunu - biri diğeriyle nasıl etkileşime girer? Veya farklı bir tane - uygulamanın iş mantığını uygulama içi mantığından ayırma sorunu; Bu, uygulamanın mimarisi açısından nasıl performans göstermeli? Onlar sayesinde farklı mimari katmanlar için çeşitli tasarım desenleri dünyayı görmüş; bunlar arasında en bilinenleri:

- Singleton tasarım deseni.

Bu model, bir sınıfın yalnızca bir nesneye uygulanmasına izin verir ve bu seçenek, sistem tarafından sınırlı sayıda örnek (veya yalnızca bir örnek) onaylandığında kullanılır.

- Dekoratör tasarım deseni.

Singleton'ın aksine, bu model (alternatif olarak Adaptör modeliyle birlikte Wrapper olarak adlandırılır), belirli bir davranışın tek bir nesneye (statik veya dinamik olarak) eklenmesine izin verir ve tüm bunları diğer nesnelerin davranışını etkilemeden yapar. ile bir sınıf paylaşır.

- Köprü tasarım deseni.

İlk olarak, "Tasarım Kalıpları" kitabının yazarları olan ünlü Dörtlü Çete tarafından tanıtılan bu mimari kalıp, "kapsülleme, toplama kullanır ve sorumlulukları farklı sınıflara ayırmak için kalıtımı kullanabilir. programlama çok kullanışlı hale gelir çünkü bir programın kodundaki değişiklikler, program hakkında minimum ön bilgi ile kolayca yapılabilir. [Kaynak: Wiki]

Bu kalıplar oldukça farklı olmasına rağmen, kod yazarlarının ortak sorunları her birinde ortaya çıkmıştır; örneğin, Singleton'ın “kitleselliği” ile. Singleton çok geneldir, çünkü kodunuzun bağımlılıkları, arayüzlerde açığa çıkmak yerine uygulamanızın derinliklerinde gizlidir. Bu nedenle yazılım geliştirme sürecinde sürekli olarak yeni kalıplar ortaya çıkar.

En sık kullanılan 4 kalıp MVC, MVP, MVVM ve VIPER'dir (esas olarak iOS için).

Listelenenlerle aynı sırayla geliştirilen hepsinin kendi yararları ve kusurları vardır ve her birinin nereye uygulanacağı konusunda sayısız anlaşmazlığa neden olur. Uyguladıkları en iyi uygulamalara biraz daha dikkat etmek, işleri biraz netleştirebilir.

MVC deseni

İlk olarak 1970'lerin başında Norveçli bir bilgisayar bilimcisi Trygve Reenskaug tarafından tanıtılan tüm yazılım kalıplarının dedesi, yaygın olarak MVC olarak bilinen Modül - Görünüm - Denetleyici, Nesneye Yönelik Programlamanın ilk model yaklaşımlarından biridir.

Görünüm bölümü, sistem kullanıcısı için her şeyi görüntülemekten sorumludur (mobil veya web uygulamasının arayüzleri vb.). Model genellikle veritabanlarından, ticari kuruluşlardan ve verilerin geri kalanından sorumludur. Kontrolör ise Model'in çalışmasını, veri tabanına sağlanan verileri, bahsedilen veri tabanından Görünüm bölümüne ve tam tersi şekilde görüntülenmesini düzenler.

MVC modeli ne kadar evrensel olursa olsun, en büyük iki rakip olan Apple ve Google'ın Model - Görünüm - Denetleyici sistemini temsil eden kendi kalıpları vardır. Apple'ın sisteminin sorunu, Görünüm ve Denetleyici parçaları arasındaki sıkı bağlantıda, neredeyse Görünüm ve Denetleyiciyi birleştirecek kadar sıkı ve Model parçasını ayrı bırakıyor.

Sonuç olarak, zayıf test süreci ile sonuçlanır - sadece Model incelenebilir, V&C (sahip oldukları sıkı bağlantı nedeniyle) hiç test edilemez.

Denetleyici ve Görünüm segmentleri arasındaki güçlü bağlantının, konu yazılım olduğunda gerçekten "sağlıksız" olduğu kanıtlandı, bu nedenle dünyayı yakında yeni bir model gördü.

MVP modeli.

Birçoğumuz bu kısayolu Minimum Uygulanabilir Ürün bağlamında duyduk, ancak yazılım mühendisliği açısından bu farklı bir anlama geliyor. Model View Presenter modelinin birkaç önemli noktası vardır ve bu, onunla MVC arasında büyük bir uçurum oluşturur:

MVP Modeli

• Görünüm, modele daha gevşek bir şekilde bağlanmıştır. Modeli Görünüme bağlamaktan Sunucu sorumludur.

• Görünümle etkileşim bir arayüz aracılığıyla olduğundan birim testi daha kolaydır.

• Genellikle Sunucuya Görüntüle = bire bir eşleyin. Karmaşık görünümlerde birden fazla sunucu olabilir.

MVC Kalıbı

• Denetleyiciler davranışlara dayanır ve görünümler arasında paylaşılabilir

• Hangi görünümün görüntüleneceğini belirlemekten sorumlu olabilir
  [Kaynak: Infragistics]

Bu düzenlemede Model'in işlevleri aynı kalır; Sunucu sırasıyla iş mantığından sorumludur. V kısmı, özellikle ilgi çekici olanıdır - çünkü etkileşim için yetkili olan iki bölüme Görünüm ve Görünüm Denetleyicisi'ne ayrılmıştır. Bir MVVM vs MVC sorusu olduğunda, bu tür sistem, MVC modelinde kullanılan "ağır bağımlılık" Görünüm ve Denetleyici modları sorununu çözer.

Test engeli bu durumda da çözülür, Model, Kullanıcı etkileşimli Görünüm ve Sunucu bölümleri - bunların tümü test edilebilir.
Henüz mevcut olan rahatsızlık, Presenter'ın payına düşüyor - yine de çok büyük, ancak mevcut tüm iş mantıklarını hesaba katıyor. İşte bu yüzden bir sonraki perde devreye girdi, adı…

MVVM deseni

2005 yılında Microsoft'un mimarlarından John Gossman tarafından bir Model-View-ViewModel yazılım mimari modeli oluşturuldu. MVVM modelinin üç temel bileşeni sırasıyla şunlardır:
Model, “iş ve doğrulama mantığı ile birlikte bir veri modeli içeren uygulamanın etki alanı modelinin bir uygulamasıdır. Model nesnelerine örnek olarak havuzlar, iş nesneleri, veri aktarım nesneleri (DTO'lar), Düz Eski CLR Nesneleri (POCO'lar) ve oluşturulan varlık ve proxy nesneleri dahildir." [Kaynak: Microsoft]

Görünüm yine kullanıcının görebildiği her şeydir - ekrandaki her şeyin düzeni, yapısı ve görünümü. Temel olarak, uygulama içinde uygulamanın sayfası olacaktır. View, bu parça ile Modelin kendisi arasındaki tüm iletişim dışında, yalnızca ViewModel'e güncellemeler alır ve gönderir.

ViewModel'in, View ve Model sistem bileşenleri arasında bir "bağlantı zinciri" olduğu varsayılır ve ana işlevi, View'in mantığını idare etmektir. Tipik olarak, görünüm modeli, model sınıflarındaki yöntemleri çağırarak modelle etkileşime girer. Görünüm modeli daha sonra, Microsoft'un belirttiği gibi, görünümün kolayca kullanabileceği bir biçimde modelden veri sağlar.

MVC ve iOS MVVM arasındaki temel fark , MVVM'nin dağıtım modelinin daha önce listelenen MVC'den daha iyi olmasıdır, ancak MVP ile karşılaştırıldığında, aynı zamanda büyük ölçüde aşırı yüklenmiştir. Test etme burada özellikle önemlidir, çünkü kodu açıkça yazarken tüm projenin düzgün çalışacağını garanti edemezsiniz - testler, parlak notta, çalışacağından emin olmanıza yardımcı olur.

Bir sonraki mimari modellerin evrimi yakın zamanda piyasaya sürüldü ve şu anda en yeni yazılım mimari yaklaşımı.

iOS VIPER mimarisi

Sunmak için en iyi mimari çözümü arayan dünyanın dört bir yanındaki iOS geliştiricileri, Bob Amca tarafından dünya çapındaki yazılım profesyonelleri için eğitim oturumları sağlayan iyi bilinen bir platform olan Temiz Kodlayıcılar'da tanıtılan “Temiz Mimari” yaklaşımıyla karşılaştı.

Temiz Mimari, uygulamanın mantıksal yapısını birkaç sorumluluk düzeyine böler. Sırasıyla, bu “ayrılık”, sıkı bağımlılık sorunlarını çözer ve tüm seviyelerin test kullanılabilirliğini artırır.

ios geliştirme için VIPER

VIPER, iOS tarafından oluşturulmuş uygulamalar için bir Temiz Mimari uygulamasıdır. Tüm kalıpların adları için ortak bir kural olarak, View, Interactor, Presenter, Entity ve Routing için de bir arka addır. VIPER'in her bir parçası belirli bir unsurdan sorumludur, özellikle:

1. Görünüm, kullanıcının bir arayüzle yaptığı eylemleri yansıtmaktan sorumludur.

2. Sunucunun VIPER modeli içindeki sorumlulukları oldukça sınırlıdır - Entity'den güncellemeleri alır, ancak ona herhangi bir veri göndermez;

3. Interactor, sistemin Varlıklara karşılık gelen kısmıdır. Bu şema şu yönde çalışır: Presenter Interactor'a Görünüm modelindeki değişiklikler hakkında bilgi verir, ardından Interactor Entity bölümüyle iletişime geçer ve Entity Interactor'dan alınan verilerle Presenter'a geri döner, bu da View'a bunu bir kullanıcı için yansıtması için komut verir. Tüm veri modelleri, tüm varlıklar ve tüm web siteleri Interactor kısmına bağlıdır.

4. Entity, Interactor tarafından kontrol edilen nesnelerden (başlıklar, içerik vb.) oluşur. Presenter ile hiçbir zaman doğrudan etkileşime girmez, sadece I-part aracılığıyla.

5. Yönlendirme (veya bazen adlandırıldığı gibi Tel Çerçeve), tüm ekranlar arasında gezinmeden ve esasen yönlendirmeden sorumludur. Wireframe, UIWindow, UINavigationController ve benzerlerinin nesnelerini kontrol eder.

Özellikle iOS mimari sistemi içinde, tümü, Apple MVC'nin tüm bileşenlerini içeren, ancak daha önce kodlayıcıları çıldırtmak için kullanılan sıkı bir bağlantı olmadan, UIkit adlı bir çerçeve üzerine inşa edilmiştir.

VIPER modülü, harika modelin dağılımı, mevcut tüm işlevleri test etmenize izin verdiğinden, birim testleri söz konusu olduğunda da faydalıdır. Birçok yönden bu, geliştiricilerin önceki MVC, MVP ve MVVM yazılım modelleriyle karşılaştığı ana zorluktu.

Hepsini taçlandırmak için.

Bu 4 yazılım tasarım modelinin tümüne genellikle iOS geliştirme için en iyi mimari Modellerden biri denir, ancak bunların hepsi idealden daha az ve geliştirdiğiniz her proje için kesinlikle evrensel olarak kullanılmasa da. Kasvetli tarafta, her modelin sahip olduğu sorunların kısa bir listesi:

• MVC, MVP, MVVM - hepsinde bu "sıkı bağlantı" sorunu var, bu da geliştirme güncellemelerini tanıtmayı ve daha sonra bunları test etmeyi oldukça zor bir görev haline getiriyor.

• VIPER vs MVVM, MVC veya MVP'nin kazanan bir dava olduğu düşünülüyor; yüksek esnekliğine ve mükemmel test edilebilirliğine rağmen, üretilmesi zor olan birçok nüansı da vardır.

%100 katı bir çözüm var mı? Pek değil, ancak projelerinizin her biri için bu 4 iOS uygulama modelinden biri tam da ihtiyacınız olan şey olabilir. Ve eğer değilse, o zaman ikisinin bir karışımı olurdu. Ya da belki üç. Şansın cesurlardan yana olduğu söylenir, öyleyse neden yazılım tasarım kalıplarıyla cesurca oynamıyorsunuz?

Max Mashkov ve Elina Bessarabova tarafından yazıldı.