Perchè adottare un pattern di presentazione dei dati MVVM explained

1. Model View ViewModel
In medio stat virtus
Mauro Servienti
Microsoft MVP - Visual C#
Senior Software Architecht @ Gaia
http://milestone.topics.it/
mauro.servienti@gmail.com

2. Agenda
• Preambolo...
• Overview
• Anatomia
• Magagne :-)

3. Qualche cosa dobbiamo dircela...
M-V-VM: PREAMBOLO

4. Domandoni... :-)
• Che cosa ci deve far paura e perchè?
– static...
– new...
– ServiceProvider.GetService<T>();
• Cosa è Dependency Injection?
• Cosa è Inversion of Control?

5. static
• Come lo testiamo?
– E se mantiene uno stato?
• Se vogliamo cambiare il comportamento?

6. new
• Come lo testiamo?
• Se vogliamo cambiare il comportamento?

7. Dependency Injection
• lo testiamo :-) Mock to the max!
• Iniettiamo tutti i comportamenti che vogliamo
– Può essere fatta via «ctor» o via «prop»
• Optional vs Mandatory

8. Inversion of Control (1)
• Qualcuno un giorno sentenziò:
– Luke: program to an interface... Mumble mumble...
• Ok, va bene, bello, figo, ma...: «new» is evil :-)

9. Inversion of Control (2)
• Deleghiamo il lavoro sporco! Tanto abbiamo
capito cosa è DI;

10. Please, welcome «ServiceProvider»
• Activator.CreateInstance(): la preistoria di IoC
• Fx 1.0: IServiceProvider.GetService( Type svc );
• Perchè?
– Lifetime!!!!
• Gli errori da non commettere:
– DI diretta sul container;
– «ServiceLocator» pattern... Blehaha...: è static;
• Il container è uno sconosciuto e tale deve
restare :-)

11. Tutti ne parlano... Ma che cosa è?
M-V-VM: OVERVIEW

12. Please welcome M-V-VM
Il centro del
mondo!
ViewModel
Repository<T>
Somewhere in
time...
D.I.
View
DataBinding
Command
data engine presentation
Model
Adapter

13. Overview
• mediatore della comunicazione;
• Il designer non deve scrivere codice;
• sfrutta il potentissimo motore di DataBinding e di
Commanding di Wpf;
• permette di «appiattire» un grafo, la UI è piatta!
• aggiunta di behavior ad un grafo:
– e.g. Delete command su una row;
• aggiunta di informazioni ad un grafo:
– e.g. proprietà calcolate, che non avrebbero senso sul
dominio;
• semplificazione dello xaml perchè può ridurre
drasticamente l'uso dei converter;

14. Smontiamolo :-)
M-V-VM: ANATOMIA

15. Anatomia
• È una banale classe che implementa
INotifyPropertyChanged e basta! :-)
• Si potrebbe essere tentati di dipendere da
DependencyObject
– ma introduciamo una dipendendenza da tutto
Wpf al solo scopo di avere la notifica simile a
INotifyPropertyChanged

16. Demo
ITALIANI! FACCIAMOLO...

17. Anatomia: considerazioni
• View first o ViewModel first?
– La blendability è importante;
– Come comunicano View e ViewModel:
• Uno per tutti: Intercettare la chiusura della View
• In ottica DI 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;

18. Pregi & Difetti
• + Testabilità della logica della UI;
• + Sostituibilità della UI (stesso View Engine);
• + Elevata manutenibilità;
• - Aumento della complessità e mancanza di
“controllori” (San csc.exe non aiuta...);
• - il data binding non risolve tutti gli scenari...
dobbiamo sporcarci le manine... 

19. Bello... ma che sudate!
M-V-VM: MAGAGNE

20. Non è tutto oro quel 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 vostro concetto di
produttività:
– pessimo supporto dei designer visuali;
– struttura della solution obbliga alla rebuild;
– possiamo testare tutto, quasi;
– Elevatissima manutenibilità;
• è performante? Si, ma che importa? :-)

21. See it: live!
VEDIAMO UN PO’ DI SOLUZIONI...

22. Metto le cuffie :-)
DOMANDISSIME...?