Mauro ci parla di Model View ViewModel. Durante lo sviluppo di un’applciazione complessa ci devono spaventare:
- static: come lo testiamo? E se mantiene uno stato? Se vogliamo cambiare il comportamento?
- new: come lo testiamo? Se vogliamo cambiare il comportamento?
- Serviceprovider.GetService<T>()
Esternalizzando le dipendenze, dependency injection, possiamo di risolvere questi problemi, possiamo testare e mockare come volgiamo e possiamo iniettare tutti i comportamenti che vogliamo. In particolare l’injection possiamo farla via costruttore o via property (optional vs Mandatory). Introduciamo quindi le interfacce e mediante IoC chiediamo a qualcun altro di istanziare la classe concreta per noi. Naturalmente in un’applicazione corposa questo meccanismo potrebbe far esplodere il codice, inoltre per i servizi può essere inutile avere un’istanza nuova per ogni richiesta.
Model View ViewModel fa, con modalità diverse, la stessa cosa di Model View Presenter: separa la presentazione dei dati dal Model. In particolare sfrutta la potentissima infrastruttura di binding e commanding di WPF. I vantaggi sono tanti:
-
mediatore della comunicazione
-
il designer non deve scrivere codice
-
sfrutta il potentissimo motore di binding e commanding di wpf
-
aggiunta di behavior ad un grafo (es. delete command su una row)
-
semplificazione dello xaml perchè può ridurre drasticamente l’uso dei converter
Il ViewModel è una banale classe che implementa INotifyPropertyChanged e basta! Si potrebbe essere tentati di dipendere da DependencyObject ma introduciamo una dipendenza da tutto wpf al solo scopo di avere la notifica simile a INotifyPropertyChanged. Ci basta mettere un’istanza di questa classe nel datacontext della nostra view per accedere al suo contenuto. Su un dominio complesso passiamo la vita a scrivere ViewModel/DTO.
Considerazioni:
-
View first o ViewModel first?
-
In ottica Dependency Injection se il ViewModel ha delle dipendenze mandatory la View First ve la siete giocata
-
A questo punto DI ci porta verso IoC quindi è necessariamente Viewmodel First
Pregi:
Difetti:
Non è tutto oro quello che luccica:
-
Passate la vita a scrivere wrapper/dto
-
Il processo di validazione: IDataErrorInfo, ma come triggheriamo?
-
Localizzazione: LocBAML… ahahah che ridere…
-
è produttivo? Dipende da cosa intendiamo per produttivo:
-
pessimo supporto dei designer
-
struttura della solution obbliga alla rebuild
-
possiamo testare tutto, quasi;
-
elevatissima manutenibilità;
-
E’ performante? Si, ma che importa? :-)
E’ un mito quest’uomo!