MVP contro MVC contro MVVM contro VIPER. Cosa c'è di meglio per lo sviluppo iOS?

Come ogni casa ha un solido seminterrato, ogni progetto software ha un'architettura software su cui è costruito e ogni progetto ha la propria struttura di app. I tipi di modelli architetturali possono variare, ma ce ne sono 4 più comunemente usati - quelli che l'intero mondo IT critica continuamente ma continua a utilizzare allo stesso tempo: MVC, MVP, MVVM e Viper (l'ultimo come modello di architettura iOS per lo più) . Il confronto di questi modelli e la scelta di una soluzione migliore per il caso di ciascun progetto scritto da Swift verrà scoperto più avanti in questo articolo.

Seguendo l'ordine cronologico delle cose, una volta che sono comparsi i primi modelli di progettazione del software, i problemi comuni di quei modelli di architettura di sviluppo ios non hanno tardato ad arrivare.

Ad esempio, il problema della comunicazione server-client: come si interagisce con l'altro? O un altro: il problema di separare la logica di business dell'applicazione dalla logica dell'in-app; come dovrebbe comportarsi questo in termini di architettura dell'applicazione? Grazie a loro vari modelli di progettazione per diversi livelli di architettura hanno visto il mondo; i più noti tra questi sono:

- Modello di progettazione singleton.

Questo modello consente di applicare una classe a un solo oggetto e questa opzione è utile quando un numero limitato di istanze (o solo un'istanza) è approvato dal sistema.

- Modello di design del decoratore.

A differenza del singleton, questo pattern, (chiamato in alternativa Wrapper insieme al pattern Adapter), permette di aggiungere un comportamento specifico ad un singolo oggetto (sia staticamente che dinamicamente), e tutto questo senza influenzare il comportamento di altri oggetti questo si condivide una classe con.

- Modello di progettazione del ponte.

Introdotto per la prima volta dal famigerato Gang of Four - autori del libro "Design Patterns", questo modello architetturale "usa l'incapsulamento, l'aggregazione e può utilizzare l'ereditarietà per separare le responsabilità in classi diverse. Quando una classe spesso, le caratteristiche dell'orientamento agli oggetti la programmazione diventa molto utile perché le modifiche al codice di un programma possono essere apportate facilmente con una conoscenza preliminare minima del programma. [Fonte: Wiki]

Nonostante questi modelli siano piuttosto diversi, i problemi comuni degli autori di codici si sono verificati con ciascuno di essi; per esempio, con la “massività” di Singleton. Singleton è troppo globale, poiché le dipendenze del tuo codice sono nascoste profondamente all'interno della tua applicazione, invece di essere esposte nelle interfacce. Ecco perché durante il processo di sviluppo del software compaiono costantemente nuovi modelli.

I 4 pattern più comunemente usati sono MVC, MVP, MVVM e VIPER (principalmente per iOS).

Sviluppati nello stesso ordine in cui sono elencati, tutti hanno i loro vantaggi e difetti, causando numerose controversie su dove applicarli. Prestare un po' più di attenzione alle migliori pratiche che implementano potrebbe chiarire un po' le cose.

Modello MVC

Il nonno di tutti i pattern software, introdotto per la prima volta all'inizio degli anni '70 da un informatico norvegese Trygve Reenskaug, Module - View - Controller, ampiamente noto come MVC, è uno dei primi approcci di pattern della programmazione orientata agli oggetti.

La parte Visualizza è responsabile della visualizzazione di tutto per l'utente del sistema (interfacce di app mobile o web, ecc.). Il modello è generalmente responsabile dei database, delle entità aziendali e del resto dei dati. Il Titolare, a sua volta, regola il lavoro del Modello, i dati forniti al database, la visualizzazione dal suddetto database alla parte View e viceversa.

Per quanto universale possa essere il modello MVC, i due maggiori concorrenti - Apple e Google hanno i propri modelli che rappresentano il sistema Modello - Vista - Controller. Il problema che ha il sistema di Apple risiede nella stretta connessione tra le parti View e Controller, stretta quasi al punto da avere unito View & Controller, e lasciare la parte Model separata.

Di conseguenza, si traduce in un processo di test scadente: solo il modello può essere esaminato, V&C (a causa della stretta connessione che hanno) non può essere testato affatto.

La solida connessione tra i segmenti Controller e View si è rivelata davvero "malsana" quando si tratta di software, quindi un nuovo modello ha visto presto il mondo.

Modello MVP.

Molti di noi hanno sentito questa scorciatoia nel contesto di Minimum Viable Product, ma in termini di ingegneria del software significa qualcosa di diverso. Il modello Model View Presenter ha pochi punti chiave, formando un vasto abisso tra esso e MVC:

Modello MVP

• La vista è più debolmente accoppiata al modello. Il Presentatore è responsabile del legame del Modello alla Vista.

• Test unitario più facile perché l'interazione con la vista avviene tramite un'interfaccia.

• Di solito Visualizza al relatore = mappa uno a uno. Le visualizzazioni complesse possono avere più relatori.

Modello MVC

• I controller si basano sui comportamenti e possono essere condivisi tra le visualizzazioni

• Può essere responsabile della determinazione della vista da visualizzare
  [Fonte: Infragistics]

In questa disposizione le funzioni del Modello rimangono le stesse; Il presentatore è responsabile rispettivamente della logica aziendale. La parte V è quella di particolare interesse, in quanto divisa in due parti View e View Controller, che hanno autorità per l'interazione. Quando c'è una domanda MVVM vs MVC, il sistema di questo tipo risolve il problema di una modalità di visualizzazione e controller "pesante" utilizzata per avere nel modello MVC.

L'ostacolo del test è risolto anche in questo caso, poiché le parti Modello, Visualizza con interazione dell'utente e Presentatore: tutte queste possono essere testate.
L'inconveniente ancora esistente è da parte di Presenter - ma troppo massiccio, ma tiene conto di tutte le logiche di business esistenti. Ecco perché è entrato in gioco il prossimo atto, chiamato...

Modello MVVM

Un modello architettonico software Model-View-ViewModel è stato creato nel 2005 da John Gossman, uno degli architetti di Microsoft. I tre componenti principali del modello MVVM sono rispettivamente:
Il modello è “un'implementazione del modello di dominio dell'applicazione che include un modello di dati insieme alla logica di business e di convalida. Esempi di oggetti modello includono repository, oggetti business, oggetti di trasferimento dati (DTO), Plain Old CLR Objects (POCO) e entità generate e oggetti proxy. [Fonte: Microsoft]

La vista è di nuovo tutto ciò che l'utente è in grado di vedere: il layout, la struttura e l'aspetto di ogni cosa sullo schermo. Fondamentalmente, all'interno dell'applicazione sarebbe la pagina dell'app. View ottiene e invia aggiornamenti solo a ViewModel, escludendo tutte le comunicazioni tra questa parte e il modello stesso.

ViewModel dovrebbe essere una "catena di interconnessione" tra i componenti del sistema View e Model, e la sua funzione principale è quella di gestire la logica della View. In genere, il modello di visualizzazione interagisce con il modello richiamando metodi nelle classi del modello. Il modello di visualizzazione fornisce quindi i dati dal modello in una forma che la visualizzazione può utilizzare facilmente, come afferma Microsoft.

La principale differenza tra MVC e iOS MVVM è che il modello di distribuzione di MVVM è migliore rispetto a MVC precedentemente elencato, ma rispetto a MVP è anche enormemente sovraccaricato. Il test è una questione di particolare importanza qui, poiché mentre si scrive chiaramente il codice non si può garantire che l'intero progetto funzionerà correttamente - i test, sulla nota positiva, aiutano a garantire che funzionerà.

La prossima evoluzione dei modelli architetturali è stata rilasciata di recente ed è ora l'approccio architetturale software più recente.

Architettura iOS VIPER

Alla ricerca della migliore soluzione architetturale da fornire, gli sviluppatori iOS di tutto il mondo si sono imbattuti in un approccio chiamato "Architettura Pulita", introdotto da Uncle Bob su Clean Coders, una piattaforma ben nota che fornisce sessioni di formazione per i professionisti del software di tutto il mondo.

L'architettura pulita suddivide la struttura logica dell'applicazione in diversi livelli di responsabilità. A sua volta, questa "separazione" risolve i problemi di stretta dipendenza e aumenta la disponibilità dei test a tutti i livelli.

VIPER per lo sviluppo di iOS

VIPER è una realizzazione di Clean Architecture per applicazioni iOS. Come regola comune per tutti i nomi dei modelli, è anche un backronym per View, Interactor, Presenter, Entity e Routing. Ciascuna delle parti del VIPER è responsabile di un determinato elemento, in particolare:

1. View è responsabile del mirroring delle azioni che l'utente fa con un'interfaccia

2. Le responsabilità del relatore all'interno del modello VIPER sono piuttosto limitate: riceve gli aggiornamenti dall'entità, ma non gli invia alcun dato;

3. Interactor è la parte del sistema che corrisponde effettivamente alle Entità. Questo schema funziona nella seguente direzione: Presenter informa Interactor delle modifiche nel modello View, quindi Interactor contatta la parte Entity e, con i dati ricevuti da Entity Interactor torna a Presenter, che comanda a View di rispecchiarlo per un utente. Tutti i modelli di dati, tutte le entità e tutti i siti web sono collegati alla parte Interactor.

4. L'entità è costituita da oggetti controllati da Interactor (titoli, contenuti, ecc.) Non interagisce mai direttamente con Presenter, solo tramite I-part.

5. Il routing (o Wireframe come viene talvolta chiamato) è responsabile della navigazione tra tutte le schermate e, essenzialmente, del routing. Wireframe controlla gli oggetti di UIWindow, UINavigationController e così via.

In particolare all'interno del sistema architettonico iOS è tutto costruito su un framework chiamato UIkit, che include tutti i componenti di Apple MVC, ma senza una connessione stretta che prima faceva impazzire i programmatori.

Il modulo VIPER è anche vantaggioso quando si tratta di test unitari, poiché la grande distribuzione del modello ti consente di testare tutte le funzionalità disponibili. Per molti versi questa è stata la principale difficoltà che gli sviluppatori hanno dovuto affrontare con i precedenti modelli software MVC, MVP e MVVM.

Per coronare il tutto.

Tutti questi 4 modelli di progettazione del software sono spesso definiti uno dei migliori modelli di architettura per lo sviluppo di iOS, anche se tutti non sono ideali e sicuramente non sono universalmente utilizzati per ogni progetto che si sviluppa. Dal lato cupo, ecco un breve elenco di problemi che ogni modello ha:

• MVC, MVP, MVVM : tutti hanno questo problema di "connessione stretta", che rende l'introduzione di aggiornamenti allo sviluppo e il loro test in seguito un compito piuttosto difficile da svolgere.

• VIPER vs MVVM, MVC o MVP , si pensa sia un caso vincente; sebbene nonostante la sua elevata flessibilità e grande testabilità abbia anche molte sfumature difficili da generare.

Esiste una soluzione solida al 100%? Non proprio, ma per ciascuno dei tuoi progetti uno di questi 4 modelli di app iOS potrebbe essere proprio quello di cui hai bisogno. E se non lo è, allora sarebbe una miscela di due. O forse anche tre. Si dice che la fortuna favorisca gli audaci, quindi perché non giochi audacemente con i modelli di progettazione del software?

Scritto da Max Mashkov ed Elina Bessarabova.