Da Visual Studio 2019 Preview approntate tutto per creare un nuovo progetto: scegliendo la voce Blazor sarà possibile al set di template dedicati.

Template tipo 1 - Blazor Server App (anche chiamata al bar amichevolmente Blazor server-side)

Template tipo 2 - Blazor WebAssembly App (al bar viene chiamato Blazor client-side)

Template tipo 3 - Blazor WebAssembly App hosted in Asp.Net Core (anche chiamata amichevolmente Blazor client-side hosted in Asp.Net core server)

Oss.: Giustamente potete osservare che le voci proposte dal nostra amato Visual Studio sono solo due, ma prima di pensare che possa aver detto una fesseria date un’occhiata al flag in basso a destra nominato Asp.Net Core hosted: questo permette di creare i template 2 e 3. Lo stesso flag è indisponibile se si sceglie il template 1.

I template esposti propongono in sostanza due “hosting-model” di Blazor: il primo template permette un hosting di tipo server-side, gli altri due client-side.

Ora parlare del modello di hosting model Blazor così, a freddo, mi rendo conto che è un po' da sciagurati: ma ci provo lo stesso e, siccome il blog è mio e decido io cosa metterci, ho deciso di proporre in questo momento questi concetti, in modo tale che nel prossimo li possiate raffinare e comprendere appieno.

Torniamo bomba: i template 2 e 3 predispongono dei progetti nei quali il codice in esecuzione sul browser sarà scritto in C# e mandato in esecuzione nel browser con l’ausilio di webassembly.

Ma quale è la differenza tra questi due template ? Il template 2 è una pura web-app Blazor: in pratica crea solo i file necessari a essere mandati in esecuzione sul browser, e quindi è una pura web-app client-side.

In questo ultimo periodo anche io ho subito il fascino di Blazor, il nuovo sistema framework per scrivere web-app in salsa M$.

Sin dal primo momento che mi sono approcciato all’argomento mi sono reso conto che questo l’argomento è veramente una gran figata: so di non essere molto professionale ad usare un termine del genere, ma direi che rende l’idea di quello che umilmente ne penso.

Di questo nuovo framework mi è da subito piaciuto da subito l’approccio alla programmazione proposto, non certo elegante, ma efficace e comprensibile.

Eppoi questo stile di programmazione, che miscela HTML con C#, mi ricorda i tempi gloriosi di asp/vbscript: boh, non so, forse è una mia idea balorda, ma alcuni punti di incontro tra questi due mondi così lontani nel tempo francamente li vedo.

In modo meno prosaico posso continuare dicendo che la cosa che più mi ha convinto di Blazor è la possibilità di scrivere web-app dotate di una robusta logica di funzionamento lato client (Angular-style per capirsi) senza dover utilizzare nulla che ha a che fare con javascript o typescript.

Per inciso: contro javascript non ho nulla, semplicemente è un linguaggio che non mi è mai piaciuto molto. ….tra di noi non c’è mai stata la scintilla, ecco…... Anche il suo cugino typescript non mi ha mai convinto eccessivamente.

Inoltre un’altro motivo a supporto di questa "mancata simpatia è il seguente". Sino all’arrivo di Blazor per implementare una moderna web-app occorreva scrivere il codice costitutivo utilizzando C# (o similari) per implementare la logica lato server, e quindi utilizzare forzatamente javascript o typescript per implementare la logica lato client.

Questo continuo switch “della testa” tra due linguaggi mi ha sempre messo in difficoltà: sarà anche l’età ?!?!?!

Comunque sia con Blazor possiamo dimenticarci (..o quasi) di usare javascript/typescript per scrivere codice che implementa logica lato client, e usare sempre e comunque C#, il che secondo me non è cosa da poco.

I vantaggi principali dell’adozione degli unit test sono molteplici: occorre solo valutare se lo sforzo profuso viene ripagato dai vantaggi ottenuti.

> Gli unit test minimizzano l’eventualità che le modifiche introdotte possano in qualche modo inficiare il comportamento del software già rilasciato: detto in altri termini cercano di evitare che quando si eseguono delle modifiche per implementare nuove feature, o anche per risolvere qualche malfunzione, si introducano dei breaking change o anche veri e propri bachi su parti precedentemente funzionanti.

> Scrivere codice adatto per essere testato con gli unit test inevitabilmente obbliga ad utilizzare un’architettura il più possibile aderente ai migliori pattern di programmazione (vedi S.O.L.I.D. e KISS, e in particolare Dependency Injection e Inversion of Control).

> Per software che coinvolgono UI gli unit test favoriscono l’adozione di pattern di programmazione come MVVM o MVC, che disaccoppiano in modo consistente la parte UI dalla parte di logica, con tutti i benefici che questo apporta.

> Il codice per gli unit test documenta in modo chiaro e inequivocabile il funzionamento degli elementi del software, magari anche declinato a casi particolari o situazioni critiche.

....siete convinti ora ???

Nel seguito fornirò alcuni dettagli per implementare in modo corretto il navigator usando FreshMVVM.

La spieghescion non sarà assolutamente esaustiva, né esporrò in modo completo tutte le funzionalità offerte dal framework.

Il mio intento è semplicemente farò un crash-course che in pochi passaggi permettano di appropriarsi della tecnica necessaria per implementare un buon navigator: per tutto il resto c’è la documentazione sul sito segnalato in linkografia.

Il primo punto da sapere è che il framework si basa su una navigazione ViewModel2ViewModel, nel senso che quando si intende aprire una pagina (push) in realtà si richiamerà la ViewModel ad esso associata: mai a poi mai si farà cenno direttamente alla pagina.

Questo rende la logica i funzionamento del Navigator assolutamente compatibile con il pattern MVVM: infatti a livello di ViewModel è assolutamente permesso interagire con altre classi di ViewModel.

Ma come fa il framework ad aprire la pagina corretta se si specifica solo il relativo ViewModel ? Esiste una naming-convention che occorre seguire religiosamente e che permette al framework di risalire alla pagina grazie alle regole di associazione classe ViewModel-Pagina ad esso associata.

Tali convenzioni si basano sul fatto che ogni classe ViewModel dovrà avere il proprio nome che termina con il suffisso ViewModel, e la relativa pagina avrà analogo nome però questa volta con il suffisso Page al posto di ViewModel.

AnagraficaClientiViewModel → AnagraficaClientiPage

Al posto di ViewModel è anche possibile usare PageModel

AnagraficaClientiPageModel → AnagraficaClientiPage

Ogni ViewModel dovrà necessariamente derivare dalla classe FreshBasePageModel.