Asp.NET MVC 竪 un nuovo framework per lo sviluppo di applicazioni web alternativo al modello webform. Questo consente di utilizzare il pattern MVC per lo sviluppo di applicazioni Asp.NET, permettendo quindi una miglior separazione delle responsabilit che a sua volta porta ad una maggior manutenibilit, riusabilit e facilit nel testing.
La sessione illustrer i motivi che hanno portato alla nascita di Asp.NET MVC e le sue caratteristiche fondamentali.
Agenda:
- Storia dei framework MS per lo sviluppo web
- Introduzione a Asp.NET MVC
- Vantaggi di Asp.NET MVC
- Il pattern MVC
- Hello MVC: DEMO
- Componenti di MVC: Routing, Controller, Model, View
Come la comunicazione tra moduli 竪 evoluta per portarci a quello che oggi 竪 la Service Oriented Architecture. Quali approcci hanno funzionato e quali no. Un esempio di architettura SOA. Come si implementano i web services di tipo REST con Jersey.
Come configurare ed eseguire un applicativo PHP su Serverless in ambiente AWS; quali considerazioni mettere in campo per la gestione delle risorse, fino a far funzionare un applicativo basato su Laravel che espone delle API
In questa sessione faremo una panoramica a 360 gradi su Blazor, la nuovissima tecnologia Microsoft nata da una (geniale :-) idea di Steve Sanderson per lo sviluppo di applicazioni Web client basate su WebAssembly.
Nell'introduzione parlemermo brevemente di WebAssembly, spiegando di cosa si tratta e del perch辿 questa tecnologia abbia tutte le premesse per portare uno dei pi湛 grandi "disruptive changes" nel modo di sviluppare applicazioni Web client. Passeremo poi a Blazor esaminandone prima gli aspetti architetturali e procedendo con un behind the scenes per svelare in che modo avviene la "magia" dell'interazione con il browser. Verranno poi presentate le feature che questa tecnologia offre (template project su VS, components, layouts, binding, dependency injection, hosting) sia attraverso slides che, di pari passo, con delle demo di un'applicazione funzionante realizzata in Blazor. Vedremo poi quali sono le problematiche legate a performance, deployment e distribuzione parlando delle possibili future ottimizzazioni. Infine chiuderemo con un confronto tra Blazor e i maggiori framework ora in uso per lo sviluppo di applicazioni Web client (Angular, Vue, Knockout, ecc.) e con alcune considerazioni sull'impatto che Blazor e tecnologie simili potrebbe avere a cascata per lo sviluppo Web futuro, in una sorta di "butterfly effect" nel mondo Web client.
Come configurare ed eseguire un applicativo PHP su Serverless in ambiente AWS; quali considerazioni mettere in campo per la gestione delle risorse, fino a far funzionare un applicativo basato su Laravel che espone delle API
In questa sessione faremo una panoramica a 360 gradi su Blazor, la nuovissima tecnologia Microsoft nata da una (geniale :-) idea di Steve Sanderson per lo sviluppo di applicazioni Web client basate su WebAssembly.
Nell'introduzione parlemermo brevemente di WebAssembly, spiegando di cosa si tratta e del perch辿 questa tecnologia abbia tutte le premesse per portare uno dei pi湛 grandi "disruptive changes" nel modo di sviluppare applicazioni Web client. Passeremo poi a Blazor esaminandone prima gli aspetti architetturali e procedendo con un behind the scenes per svelare in che modo avviene la "magia" dell'interazione con il browser. Verranno poi presentate le feature che questa tecnologia offre (template project su VS, components, layouts, binding, dependency injection, hosting) sia attraverso slides che, di pari passo, con delle demo di un'applicazione funzionante realizzata in Blazor. Vedremo poi quali sono le problematiche legate a performance, deployment e distribuzione parlando delle possibili future ottimizzazioni. Infine chiuderemo con un confronto tra Blazor e i maggiori framework ora in uso per lo sviluppo di applicazioni Web client (Angular, Vue, Knockout, ecc.) e con alcune considerazioni sull'impatto che Blazor e tecnologie simili potrebbe avere a cascata per lo sviluppo Web futuro, in una sorta di "butterfly effect" nel mondo Web client.
2. WEB 1.0
Ad ogni interazione, il browser invia una richiesta ad una
specifica risorsa (URL) con dei parametri associati alla richiesta.
Il web server risponde con lintera pagina: HTML+CSS+Javascript
La pagina contiene sia il codice necessario alla sua
renderizzazione, sia i dati.
una caratteristica storica di html over http
Inoltre il client 竪 pi湛 o meno stupido:
business logic e presentazione sono interamente in mano al server
3. WEB 1.0: flaws
I dati non sono trattati come first class objects
(non hanno n辿 tipo, n辿 struttura, n辿 vincoli).
Presentation Flow e Data Interchange, che sono ortogonali,
risultano strettamente accoppiati, uno non pu嘆 avvenire senza
che avvenga laltro (Ajax, alternativo a hmtl over http, li
disaccoppia).
Non supporta server push.
Esiste un web framework server-side che non abbia tali difetti?
4. RIA (web 2.0)
Al primo accesso alla web application, viene scaricato il
codice client della webapp stessa.
Il browser 竪 il contenitore dellapplicazione.
Da questo punto, se il client ha bisogno di dati che non ha, o
se deve aggiornare/aggiungere dati, invia una richiesta al
server.
Il server invia/aggiorna i dati (quelli che lutente 竪
autorizzato a vedere/aggiornare solo il server pu嘆
garantire la sicurezza).
La presentazione dei dati allutente viene gestita lato client.
5. RIA Architecture
Un paper illuminante: Life above the Service Tier:
Had we but invested in clientside JavaScript half the resources we invested in
serverside Java, we could have had AJAX far earlier (and we could have
avoided wasting our time on fifty different Front Controller frameworks).
MVC sul client: presentation flow tramite javascript magic:
Single Page Application.
Ajax per disaccoppiare presentation flow e data interchange
XML o JSON restituiscono dignit ai dati
7. SmartClientTM RIA Framework
Since 2001, architettura client side MVC, Ajax da prima che
esistesse lacronimo.
LGPL da 11/2007 (parte client).
Perfettamente in linea con larchitettura SOFEA.
Componenti client molto ricchi.
Ampia compatibilit coi browser (IE6 ancora compatibile con la
release 10 uscita a fine 2014), anche sul mobile.
Sistema di databinding client/server: i business objects sono
modellati nelle DataSource che sono condivise tra client e
server.
Tramite le DataSource stesse 竪 disponibile un motore di
persistenza molto efficace (oppure connettori per
JPA/Hibernate).
8. SmartClient DataSources
Il mio consiglio 竪, se possibile, di usare le SQLDataSource,
possibilmente con licenza Power (ovviamente a patto di
usare un db relazionale).
La velocit di sviluppo che si ottiene rispetto ad altri
framework e anche rispetto ad altri ORM (Hibernate,
myBatis) vale la spesa.
Ovviamente richiede maggiori conoscenze del framework
rispetto ad utilizzare solo la versione LGPL ad es.
9. Licensing
LGPL -> solo parte client (esclusi alcuni moduli)
A costi crescenti:
Pro
Power
Enterprise
Moduli a parte:
RealTime Messaging (AKA server push)
Analytics (OLAP/Datacube)
10. Exploring SmartClient
Il pacchetto contiene una SDK con un tomcat e un HSQLDB
embedded con documentazione ed esempi ricercabili ed
editabili.
La documentazione 竪 molto ben fatta, ma per i principianti 竪 un
po difficile visualizzare la big picture viste le dimensioni del
framework.
consigliabile iniziare dalla quick start guide, per poi
approfondire le tematiche nella cartella Concepts della
Reference (e nella cartella Java Server Reference se si utilizza la
parte server).
Fondamentale smanettare sugli esempi ed iniziare da subito ad
utilizzare la developer console.
12. Coding in SmartClient
In SmartClient, loggetto ClassFactory 竪 alla base di un
meccanismo di vera ereditariet per oggetti Javascript.
Questo significa che con gli oggetti SmartClient 竪 possibile
invocare metodi delle superclassi, avere attributi e metodi
di istanza ma anche statici.
ClassFactory 竪 un sigleton che viene utilizzato
principalmente per definire nuove classi:
ClassFactory.defineClass("MyClass", MySuperClass");
Per creare unistanza:
ClassFactory.newInstance(MyClass);
13. Coding syntactic sugar
isc.defineClass("MyListGrid", "ListGrid").addProperties({
headerHeight: 40, // cambia default per listGrid.headerHeight
// override listGrid.recordClick
recordClick: function (viewer, record) {
isc.say(record.description); // invece di alert()
}
})
isc.MyListGrid.create({ // crea uninstanza della nuova classe
ID: fooGrid // variabile globale
});
fooGrid.fetchData(
{STATE: ACCEPTED}, // criteria
function(dsResponse, data, dsRequest){ // callback
isc.logEchoAll(data);
}
})
Il prefisso isc. 竪 necessario se si usa il Portal mode