Sto lavorando con Xamarin e stiamo seguendo il modello di progettazione MVVM. Per coloro che non sanno cosa sia Xamarin, è una tecnologia che ci consente di costruire app iOS e Android con codice condiviso. Fondamentalmente, la tua soluzione ha 3 progetti, un "core" e poi uno per piattaforma, la piattaforma contenente tutto il codice specifico della piattaforma, come animazioni dell'interfaccia utente, elementi dell'interfaccia utente o accesso al GPS e hardware / software complessivo specifico del dispositivo. p>
Per l'esempio, assumerò che stiamo lavorando a un progetto Xamarin.iOS, con un progetto Core che ha la maggior parte della logica.
La mia situazione era la seguente, il progetto è stato scritto e amp; rilasciato con troppa codifica in UIViewControllers del progetto iOS, con conseguente maggior lavoro per gli sviluppatori Android. Il mio compito era quello di refactoring quei controller e spostare il codice in viewmodels perché molto è stato un errore.
Il problema è che l'architetto del team pensa che l'abbia spinto troppo lontano. Userò esempi reali.
Si noti che utilizziamo un sacco di oggetti Action per gestire le chiamate asincrone. Questo è un altro dibattito.
Supponiamo di avere dati da caricare, Beneficiaries , Accounts e Currencies .
Ciò richiede 3 servizi nel ViewModel e il 6% diAction s. Uno xxxxServiceLoaded e xxxxServiceFailed per ciascuno dei dati da caricare.
Nell'interfaccia utente, l'unica cosa che è stata fatta per il successo o il fallimento di ogni richiesta era, praticamente, sempre la stessa cosa. Stava sempre caricando una casella di selezione, quindi chiamava un'altra classe UI che gestiva il caricamento dei dati, ma era astratta e era sempre .loadData per tutti i dati caricati.
Per me, ViewModel è più o meno l'interfaccia utente, dovrebbe sapere come è assemblato e come reagisce. E seguendo questo ragionamento, ho refactored gli UIViewControllers da
-
OnCurrenciesFailed -
OnCurrenciesSucceeded - %codice% ... (ecc.)
per
- %codice%
- %codice%
- %codice%
- OnBeneficiariesFailed
Ha ridotto drasticamente la quantità di codice nel controller. Questo vale per molti controller nell'app. Stiamo parlando di almeno 10.000 righe di codice.
Ciò rimuove anche tutta la conoscenza dell'interfaccia utente. È stato detto il minimo indispensabile e solo l'interfaccia utente. "Visualizza questo testo". L'unica cosa che l'interfaccia utente esegue autonomamente è decidere come animare e dove visualizzare il testo, ad esempio. Credo che questo sia più pulito, più economico e più veloce.
Inoltre, rende il lavoro degli sviluppatori Android completamente cerebrale. Devi solo iscriverti a tutte le azioni e fare ciò che ti dicono. "Visualizza uno spinner". Non importa perché lo fai e basta. È più facile, molto più facile, che lasciare che il controller sappia che c'è una valuta, che sta caricando e che cosa mostrare quando ha fallito o meno. Per me, questa logica dovrebbe essere condivisa e non nascosta in un controller.
Ma il progettista ha rifiutato la mia versione, dicendo che il ViewModel sarebbe troppo strettamente accoppiato alla vista, rendendolo non intercambiabile se necessario in futuro, e che era più di un pattern di progettazione MVVMP (Presenter), che non è quello che stanno facendo.
In genere sono d'accordo sul fatto che sarebbe più accoppiato, ma non ho mai visto nessuno scambiare ViewModel o visualizzazioni e il "rischio" di ciò che sta accadendo presto. Lo sviluppo di Android, d'altra parte, sta accadendo e richiederà più lavoro e più navigazione nel codice ios per capire i requisiti (che è un errore!).
Questo solleva domande:
- Sto usando il modello correttamente spostando tutto in ViewModel?
- MVVM è lo schema giusto comunque? Poiché in entrambi i casi, è troppo accoppiato o non ha abbastanza codice condiviso, MVVM è davvero la scelta giusta? Sembra essere una montatura, ma la situazione in cui ci troviamo mostra un vero difetto.