Scopri come scatenare la potenza di WPF usando correttamente il pattern MVVM

Su Quora, il più noto sito di domande e risposte al mondo, molti si chiedono se nel 2020 WPF è morto.

Ogni tecnologia è stata dichiarata morta, almeno una decina di volte, e quelle che sono poi davvero state seppellite le ho sempre viste con largo anticipo.

Ad esempio Silverlight l’ho sempre visto come un cubetto di ghiaccio al sole, pronto ad essere schiacciato da un bello scarpone da montagna, dalla mancanza di supporto diffuso e dal ruolo che avrebbe dovuto avere dentro il browser. Un progetto con i giorni contati appena uscito.

WPF invece è la tecnologia sviluppata da Microsoft che permette di creare applicazioni Windows in sostituzione di Windows Forms per risolvere il problema di poter separare la parte di presentazione, le view, da quella di logica applicativa, cioè il code-behind.

Ed ha un grandissimo vantaggio, se si ha Windows a disposizione si possono sviluppare applicazioni ultra-robuste e solide come la roccia, senza dover scendere a compromessi come obbligano a fare le applicazioni web, che certo, sono più versatili, ma anche molto più fragili, nonostante gli ultimi sviluppi.

E anche nato in modo davvero virtuoso, gli architetti di Microsoft Ken Cooper e Ted Peters nel 2005 hanno inventato il pattern architetturale MVVM (Model View ViewModel) che consente di scrivere applicazioni perfettamente testabili anche senza avere una interfaccia utente, la UI, ma utilizzando anche solo unit test, grazie alla separazione tra grafica e comportamento.

In sostanza tra i vari benefici che hai ad utilizzarlo, c’è anche di poter implementare la logica dell’applicazione, senza avere subito le relative form e usecontrol.

Come funziona il pattern MVVM in WPF?

Sviluppo con .NET da 23 anni, ho iniziato quando è uscito, e nonostante abbia 39 anni, è praticamente tutta la vita che metto le mani nel codice e progetto software di alto livello, con un unico obiettivo: lavorare sereno, senza stress e con i più ampi margini di guadagno di possibili grazie all’ottimizzazione dei tempi di sviluppo.

Il pattern è diviso in 3 componenti, il Model, la View e il ViewModel, ognuna delle quali ha una sola dipendenza verso un solo componente.

• La View è la più semplice: è l'interfaccia utente, definita in codice XAML
• Il Model: sono le classi che permettono di trasferire e scrivere dati dai servizi
• Il ViewModel: si occupa di aggiornare la vista attraverso il motore di binding di WPF e di implementare la logica applicativa

Grazie a questa suddivisione è possibile separare completamente la logica applicativa dall'interfaccia utente, ottenendo tre grandi vantaggi:

1. gli sviluppatori e i grafici possono lavorare su file separati, i file .cs per gli sviluppatori e i .xaml per i grafici
2. è possibile implementare la logica applicativa anche senza avere ancora l'interfaccia grafica
3. è possibile scrivere unit test per disegnare il ViewModel e al tempo stesso avere dei test che ne verificano il comportamento

Se stai usando WPF con il code-behind, cioè il codice nella vista, e implementando ovunque il codice degli eventi facendo doppio click del mouse, stai andando in una direzione molto impervia e in salita.

La tua vita da sviluppatore e da project manager sarà stressata e piena di problemi e di stress, dovuto ritardi nello sviluppo e a clienti che giustamente si lamentano perché il software che produci è pieno di bug.

Il nostro lavoro è nato per automatizzare il lavoro degli altri, di persone incapaci di usare la tecnologia come sappiamo fare noi, non possiamo certo mettergli il bastone tra le ruote, giusto?

Il mercato premia enormemente chi è bravo a risolvere problemi, chi è sempre un passo avanti e riesce con eleganza a uscire da qualsiasi vicolo cieco, come faceva il grande mago Harry Houdini tra fine 1800 e inizio del 1900.

Vuoi essere visto come lui, in grado di compiere qualsiasi “miracolo” con il codice e consegnare progetti straordinari che risolvano davvero problemi ai tuoi clienti, o vuoi essere considerato come “quella schiappa che non ne fa una giusta”?

WPF e MVVM: i 3 errori da non fare

WPF con MVVM semplifica moltissimo lo sviluppo di applicazioni Windows e non solo, con XAML e MVVM si possono sviluppare anche applicazioni mobile che girano su Android e iPhone, con Xamarin, riutilizzando le conoscenze degli sviluppatori e del team.

L'errore numero 1 che fanno i team e le aziende è quello di scegliere un framework MVVM complicato, con molte più funzionalità di quelle che sono realmente necessarie che portano a rendere il codice molto verboso, cioè molte più righe di quante ne servirebbero.

Ti assicuro che nella mia carriera ventennale ho visto tonnellate di codice, e la maggior parte di queste, era scritta veramente con i piedi.

Uno dei motivi è che chi sviluppa molto spesso non ha tempo di dedicare ore e ore di studio, spesso centinaia di ore, per migliorare costantemente il proprio lavoro.

Così entra nel circolo vizioso del “dobbiamo farlo e dobbiamo fare in fretta”. E il codice diventa sempre più una… diciamo un deposito di immondizia, di cui ti vergogni appena chiudi Visual Studio.

Veniamo al secondo errore.

L'errore numero 2 è di richiedere, a causa del framework scelto, delle skill introvabili sul mercato, e quindi invece che semplificare enormemente lo sviluppo di applicazioni si creare un enorme collo di bottiglia, nel dipendere da sviluppatori che neanche nascosti nelle caverne di Azanulbizar (sì, da Il Signore degli Anelli, che film spettacolare) puoi trovare.

L'errore 3 è quello di utilizzare WPF come fosse Windows Forms o utilizzare il code-behind delle view, cioè dei file XAML, implementando la logica negli handler degli eventi invece che nei metodi collegati ai comandi dell'interfaccia ICommand, nel ViewModel. In questo modo si perde completamente il vantaggio di poter disaccoppiare la vista dalla logica, e si trasforma WPF in una vecchia tecnologia, invece che in qualcosa di innovativo, semplice e testabile, com'è nato.

Come vedi già fino a qui, potresti far saltare in aria progetti per i prossimi 10 anni.
E non sto scherzando, non sto esagerando per niente.

In un importante gruppo editoriale, mi sono occupato con un team alle mie dipendenze di tutto il sistema di reportistica di un gestionale per immobili, quindi bello corposo.

Prima del mio arrivo la società aveva dato in outsourcing tutto il client WPF che utilizzava WCF per comunicare con il sistema server. Questa UI era costata 600.000 euro di sviluppo.

Dopo 6 mesi, tutto buttato nel cestino, non si era salvato niente.
E questo scenario l’ho visto ripetersi decine di volte purtroppo, sempre per gli stessi motivi.

Mancanza di tempo per studiare adeguatamente, conoscere meglio le tecnologie e fare refactoring in modo continuativo.

Ci sta che ogni tanto tu e il tuo team scriviate codice non eccellente, specie se al primo colpo, ma poi è necessario passare con il bisturi e tagliare tutto ciò che è scritto male, inutile e fare un bel lifting al codice.

Del resto, chi vuole uscire con una ragazza di 30 anni che sembra una nonnina di 70, perché piena di rughe e mal tenuta?

Come utilizzare WPF nel modo corretto?

WPF è una tecnologia potente, che permette di validare i dati con un pattern molto semplice, disabilitare i pulsanti in modo automatico in base allo stato del ViewModel e gestire le eccezioni in modo centralizzato.

Per sfruttarlo correttamente però bisogna come sempre partire da basi solide, a quel punto lo sviluppo delle applicazioni e la loro manutenzione diventa un processo che si può sistematizzare, aumentando moltissimo la qualità del codice prodotto, senza clienti o utenti che chiamano continuamente e interrompono il tuo lavoro e quello del tuo team.

Puoi apparire professionale come foste il team di una multinazionale, come Google o Facebook, che dimostrano di avere sempre la situazione sotto controllo.
Ma solo se eviti questi errori fatali, e altri meno fatali, ma comunque importanti, che possono far fallire i tuoi progetti e diventare un ennesimo motivo di frustrazione invece che motivo di vanto e anche di divertimento.

Se vuoi ottenere questo obiettivo e diventare un asso dello sviluppo e ottenere applicazioni davvero mantenibili, che non hanno bug che si ripresentano di continuo e quindi non avere regressioni nel lavoro, clicca sul pulsante e chiedici di parlare con un tutor del corso di sviluppo in WPF “Da zero a WPF hero!”

Affrettati perché blocchiamo solo pochi giorni ogni anno per aziende selezionate, perché prima di tutto siamo sviluppatori che lavorano su progetti reali.

Pensa come potrà essere più facile e radioso il tuo futuro, migliorando esponenzialmente il sistema di sviluppo delle applicazioni WPF, separando correttamente i layer applicativi.

Non dovrai più sentirti stressato e sotto pressione per aver consegnato un software in cui è meglio che nessuno guardi mai il codice, ma anzi, sarai fiero di poterlo esporre come un’opera d’arte.

Sarà come mostrare non solo un ponte di Renzo Piano, ma anche i progetti, che sono essi stessi un grande capolavoro.

Inoltre, ricordati che mentre tu pensi se migliorare il tuo sistema di sviluppo e le tue competenze di C# e quelle del tuo team, altri là fuori si stanno già muovendo, perché il mercato non aspetta nessuno, ma passa sopra come un rullo compressore a chi rimane indietro.

La bella notizia è che puoi prenotare la tua call con il tutor per pianificare come fare un salto quantico e lavorare finalmente con le redini tenute saldamente tra le tue mani.