Desktop .NET con WPF e MVVM quando l'interfaccia deve supportare il lavoro vero

WPF non è morto: è il desktop giusto quando serve davvero il desktop

Ogni anno qualcuno annuncia la morte di WPF.

E ogni anno migliaia di applicazioni desktop Windows continuano a essere sviluppate e manutenute con WPF, in contesti dove il web non è la risposta giusta e il desktop rimane lo strumento più efficace per il lavoro che devono supportare.

WPF non è una scelta nostalgica.

È una scelta deliberata quando i requisiti includono rendering vettoriale ricco, binding complessi su modelli dati strutturati, integrazione con hardware locale, performance di rendering critiche, o semplicemente utenti che devono lavorare offline con applicazioni che si comportano come applicazioni, non come siti web.

La domanda che mi pongo sempre non è "perché WPF invece di una web app?".

È "quale tecnologia supporta meglio il lavoro che l'utente deve fare?".

Quando la risposta è il desktop Windows, WPF resta la piattaforma più matura, più performante e meglio integrata con l'ecosistema .NET disponibile oggi.

MVVM in WPF: perché funziona e dove si rompe

MVVM è il pattern di riferimento per WPF non per ragioni estetiche, ma perché risolve problemi reali: testabilità della logica di presentazione, separazione delle responsabilità tra UI e dominio, riusabilità dei ViewModel tra viste diverse.

Il binding system di WPF è progettato per MVVM: INotifyPropertyChanged, ObservableCollection, Command e DataTemplate sono costruiti per collegare ViewModel e View senza che nessuno dei due sappia nulla dell'altro.

Quando questo funziona bene, si può testare tutta la logica di presentazione senza aprire una finestra.

Dove MVVM si rompe in WPF è quando la View ha comportamenti complessi che non si esprimono con il binding: animazioni, focus management, scroll, interazioni con hardware.

In questi casi si usano i Behavior (da Microsoft.Xaml.Behaviors), gli Attached Property o, in ultima istanza, il code-behind con logica strettamente di presentazione.

Il code-behind non è il male: è il male solo quando contiene logica di business.

Performance in WPF: dove si perde e come si recupera

Le applicazioni WPF lente quasi sempre hanno lo stesso problema: troppi elementi nel visual tree, binding inefficienti o virtualizzazione assente sulle liste.

Il visual tree di WPF è il modello che il sistema di rendering usa per costruire l'interfaccia.

Ogni controllo aggiunge nodi.

Una DataGrid con mille righe senza virtualizzazione crea migliaia di controlli in memoria anche se l'utente ne vede venti.

VirtualizingStackPanel risolve questo problema mantenendo in memoria solo i controlli visibili.

Il binding con Mode=TwoWay e UpdateSourceTrigger=PropertyChanged su campi che cambiano spesso può causare aggiornamenti continui del visual tree.

Valutare OneWay dove la scrittura non è necessaria è spesso sufficiente per eliminare lag percepibile.

Lo strumento di riferimento per diagnosticare problemi di performance in WPF è Snoop: permette di ispezionare il visual tree live, vedere i binding attivi, identificare i re-render inutili e misurare il costo delle operazioni di layout.

Non si ottimizza ciò che non si misura.

Migrazione da Windows Forms a WPF: quando conviene e come affrontarla

La migrazione da Windows Forms a WPF non è sempre la mossa giusta.

Prima di iniziare vale la pena rispondere a tre domande: l'applicazione ha davvero bisogno di funzionalità che Windows Forms non può offrire?

Il team ha o può acquisire le competenze XAML e MVVM necessarie?

Il costo della migrazione è giustificato dal valore che produce?

Se la risposta a tutte e tre è sì, la strategia migliore è la migrazione incrementale con il pattern di interop WPF-Windows Forms: WindowsFormsHost permette di ospitare controlli Windows Forms dentro una finestra WPF, e ElementHost fa il contrario.

Questo consente di migrare finestra per finestra senza bloccare il prodotto.

La parte più critica della migrazione non è tecnica: è il refactoring verso MVVM.

Un'applicazione Windows Forms con logica di business nei form non si migra a WPF semplicemente convertendo i controlli in XAML.

Si migra estraendo prima la logica dai form in classi testabili, poi collegando queste classi ai ViewModel WPF.

Il costo tipico di una migrazione mal pianificata è il doppio di quello stimato.

Il motivo quasi sempre è che il codice esistente non aveva separazione tra UI e logica, e quella separazione va costruita durante la migrazione, non prima e non dopo.