ASP.NET MVC è una piattaforma aperta costruita come un puzzle di componenti. Per personalizzare il comportamento dei componenti interni del sistema è quindi sufficiente rimuovere uno dei tasselli e sostituirlo con uno scritto da noi. Un'operazione resa semplice ed immediata dall'interfaccia Dependency Resolver.
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.
Applicazioni Web ultra-performanti con Vue.js e DelphiMarco Breveglieri
Vue.js è un framework per creare interfacce utente estremamente performanti e che può essere introdotto progressivamente nelle vostre applicazioni Web, nel modo meno invasivo possibile. In questo talk scoprirete come utilizzarlo con Delphi creando una soluzione frontend e backend ad elevate prestazioni.
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.
Applicazioni Web ultra-performanti con Vue.js e DelphiMarco Breveglieri
Vue.js è un framework per creare interfacce utente estremamente performanti e che può essere introdotto progressivamente nelle vostre applicazioni Web, nel modo meno invasivo possibile. In questo talk scoprirete come utilizzarlo con Delphi creando una soluzione frontend e backend ad elevate prestazioni.
Back to the Future: Migrare da WebForm ad ASP.NET Core gradualmente Andrea Dottor
Molte applicazione sono (ancora) sviluppate in WebForm e non possono essere convertite automaticamente ad ASP.NET Core. Una riscrittura completa in molti casi è impossibile o impensabile da attuare. In questa sessione vedremo come migrare in modo graduale queste tipologie di applicazioni verso ASP.NET Core, andando in dettaglio nelle varie problematiche che solitamente si possono presentare. La sessione deriva da un'esperienza reale, che ha permesso di conoscere (nel bene o nel male) le difficoltà che si nascondo in queste migrazioni.
Evento: https://www.xedotnet.org/eventi/one-day-enterprise-application/
DotNetCampus - Continuous Integration con Sql ServerAlessandro Alpi
Continuous Integration con SQL Server. Come automatizzare i processi di build e di test su database SQL Server. Come includere SQL Server nei processi di Application Lifecycle Management (Database Lifecycle Management).
Sviluppo Web con React e Delphi - Seminario Delphi Day 2016, PiacenzaMarco Breveglieri
Slide del seminario sull'uso di React con Delphi e confronto con altre tecnologie (es. ExtJS) per lo sviluppo Web, tenuto al Delphi Day 2016 a Piacenza.
I sorgenti sono disponibili qui:
https://github.com/marcobreveglieri/conferences/tree/master/2016/delphi_day_2016
In ASP.NET Core 3.0 è stato introdotto il supporto a gRPC, una framework altamente performante per fare Remote Procedure Call (RPC). Leggero e molto efficiente, supportato da molti linguaggi, supporto ad una comunicazione bidirezionale, riduzione del consumo di banda...solo questi solo alcuni dei vantaggi che descrivono gRPC, e che durante la sessione cercheremo di capire se siano reali o meno.
Fatto sta che è una tecnologia assolutamente da conoscere e sfruttare nello sviluppo di app moderno, e non solamente in ambito web.
Codice: https://github.com/andreadottor/XE.Dottor.gRPC
Evento: https://www.xedotnet.org/eventi/grpc-and-c-optimising-night/
Doaw2020 - Dalla produzione alla QA, provisioning su SQL ServerAlessandro Alpi
In questa sessione vedremo come portare i dati in ambienti QA direttamente dalla produzione, evitando ogni problema conosciuto ad oggi: spazio, tempo, numero di copie, isolamento e via discorrendo. Un annoso problema che può essere finalmente risolto con pochi click.
In questa sessione vedremo come uno sviluppatore WebForm possa essere velocemente produttivo (utilizzando le ultime versioni di ASP.NET Core) grazie a Blazor. Vedremo quindi cosa differenza un'applicazione ASP.NET Core, rispetto a quelle WebForm (.NET Framework) fino ad arrivare a comprendere perchè e come Blazor possa agevolare questa transizione.
Quindi una sessione non solo per chi è nuovo a Blazor, ma anche perchì ancora non ha migrato ad ASP.NET Core.
Delphi & Dintorni Webinar - Diventa un mago del TestingMarco Breveglieri
Il Testing è una pratica sempre più preziosa e fondamentale nell'ambito dello sviluppo del software: si tratta di un passaggio fondamentale per ridurre il numero dei bug nel software e abilitare automatismi come la Continuous Integration e la Continuous Delivery. Se utilizzati in modo errato però, i test possono causare più problemi di quanti ne prevengano: è importante quindi conoscere le differenze tra le varie tipologie di test, quali sono le loro caratteristiche ideali e padroneggiarli al meglio. In questo webinar faremo luce sul Testing, chiariremo bene i concetti di Unit e Integration Test, vedremo come scriverli nel modo corretto e quali tool ci vengono in aiuto... alla fine il Testing non avrà più segreti!
Prepariamoci al cambiamento. ASP.NET MVC e ASP.NET Web API saranno unificati in un unico framework chiamato ASP.NET MVC 6, e questo è solo la prima di una serie di novità che stanno per arrivare.
Tutto si semplifica. Le performance migliorano. Un altro salto tecnologico in avanti portato da ASP.NET 5.
In questa sessione, infatti, vedremo tutte le novità che ASP.NET MVC 6 porta con se, e cercheremo di andare in dettaglio in modo da capire cosa voglia dire realizzare (da zero) o migrare (un'applicazione essitente) a questa nuova versione
ASP.NET Core 2.0 è stato ufficialmente rilasciato e porta con se parecchie novità come le Razor Pages, template aggiornati e l'integrazione con Application Insights migliorata. In questa cercheremo capiremo la vera maturità di questo framework, e quanto questo rilascio sia importante per noi dev.
Dependency injection questa sconosciutaAndrea Dottor
L'uscita di ASP.NET Core ha portato a una maggiore diffusione dell'utilizzo della DI (Dependency Injection) ma spesso senza che lo sviluppatore sappia la sua reale utilità o potenzialità.
Dependency Injection, uno dei design pattern della programmazione OOP. Una best-practice dello sviluppo che può portare alla semplificazione del codice scritto, facilitare il disacoppiamento, e migliorare la testabilità.
In questa sessione vedremo cos'è la DI e come utilizzarla intelligentemente all'interno dei nostri progetti.
Slide dell'evento "XE One Day - Good code" tenuto il 15.09.2018.
Il codice è disponibile alla pagina dell'evento https://www.xedotnet.org/eventi/one-day-good-code/
APPSTUDIO: DA ZERO ALLO STORE IN 50 MINUTI!DotNetCampus
AppStudio e' un ambiente RAD web based per lo sviluppo di Universal App (Windows Phone 8.1 e Windows 8.1) per la visualizzazioni di sorgenti dati. In questa sessione vedremo come sia facile realizzare da zero un'app che acceda a sorgenti remote e come sia, infine, possibile personalizzare il codice sorgente per poter implementare le proprie personalizzazioni.
Disegnare Web Application orientate al Mobile con MVC 4 e jQuery Mobile (We W...Giorgio Di Nardo
Le slide della mia sessione su "Disegnare Web Application orientate al Mobile con MVC 4 e jQuery Mobile" all'evento "We Want Web" organizzato a Roma da "DomusDotNet" in 9 marzo 2012.
Slide della serata post-brainpirlo con l'introduzione al design e allo sviluppo sulla piattaforma Windows Phone 7, a cura di Claudio Gandelli (Looptribe) e Michele Capra (OrangeCode)
Model View Controller - Semplificare Il Codice E Minimizzare I TempiMarco Parenzan
L’aumento della complessità delle applicazioni e la velocità di realizzazione richiesta al giorno d’oggi, hanno obbligato gli sviluppatori ad utilizzare metodologie formali per la scrittura di codice e il successivo testing dello stesso al fine di minimizzare i tempi di rilascio.
L’utilizzo dei pattern, ossia di convenzioni condivise dalla community dei programmatori, è una pratica sempre più diffusa e adottata anche per applicazioni Web.
L’ormai trentennale pattern Model-View-Controller (MVC) sta attualmente conoscendo una nuova giovinezza grazie al successo di framework nelle applicazioni Web che lo usano come riferimento.
Rails è il framework MVC più famoso e diffuso, implementato per la piattaforma Ruby, mentre ASP.NET MVC e MonoRail sono i due framework web MVC che stanno riscuotendo il maggiore successo per lo sviluppo su .NET e su Windows.
Conosceremo quindi la filosofia di riferimento e le specificità dei due framework tramite due implementazioni reali di una stessa applicazione e ne discuteremo vantaggi e svantaggi.
Back to the Future: Migrare da WebForm ad ASP.NET Core gradualmente Andrea Dottor
Molte applicazione sono (ancora) sviluppate in WebForm e non possono essere convertite automaticamente ad ASP.NET Core. Una riscrittura completa in molti casi è impossibile o impensabile da attuare. In questa sessione vedremo come migrare in modo graduale queste tipologie di applicazioni verso ASP.NET Core, andando in dettaglio nelle varie problematiche che solitamente si possono presentare. La sessione deriva da un'esperienza reale, che ha permesso di conoscere (nel bene o nel male) le difficoltà che si nascondo in queste migrazioni.
Evento: https://www.xedotnet.org/eventi/one-day-enterprise-application/
DotNetCampus - Continuous Integration con Sql ServerAlessandro Alpi
Continuous Integration con SQL Server. Come automatizzare i processi di build e di test su database SQL Server. Come includere SQL Server nei processi di Application Lifecycle Management (Database Lifecycle Management).
Sviluppo Web con React e Delphi - Seminario Delphi Day 2016, PiacenzaMarco Breveglieri
Slide del seminario sull'uso di React con Delphi e confronto con altre tecnologie (es. ExtJS) per lo sviluppo Web, tenuto al Delphi Day 2016 a Piacenza.
I sorgenti sono disponibili qui:
https://github.com/marcobreveglieri/conferences/tree/master/2016/delphi_day_2016
In ASP.NET Core 3.0 è stato introdotto il supporto a gRPC, una framework altamente performante per fare Remote Procedure Call (RPC). Leggero e molto efficiente, supportato da molti linguaggi, supporto ad una comunicazione bidirezionale, riduzione del consumo di banda...solo questi solo alcuni dei vantaggi che descrivono gRPC, e che durante la sessione cercheremo di capire se siano reali o meno.
Fatto sta che è una tecnologia assolutamente da conoscere e sfruttare nello sviluppo di app moderno, e non solamente in ambito web.
Codice: https://github.com/andreadottor/XE.Dottor.gRPC
Evento: https://www.xedotnet.org/eventi/grpc-and-c-optimising-night/
Doaw2020 - Dalla produzione alla QA, provisioning su SQL ServerAlessandro Alpi
In questa sessione vedremo come portare i dati in ambienti QA direttamente dalla produzione, evitando ogni problema conosciuto ad oggi: spazio, tempo, numero di copie, isolamento e via discorrendo. Un annoso problema che può essere finalmente risolto con pochi click.
In questa sessione vedremo come uno sviluppatore WebForm possa essere velocemente produttivo (utilizzando le ultime versioni di ASP.NET Core) grazie a Blazor. Vedremo quindi cosa differenza un'applicazione ASP.NET Core, rispetto a quelle WebForm (.NET Framework) fino ad arrivare a comprendere perchè e come Blazor possa agevolare questa transizione.
Quindi una sessione non solo per chi è nuovo a Blazor, ma anche perchì ancora non ha migrato ad ASP.NET Core.
Delphi & Dintorni Webinar - Diventa un mago del TestingMarco Breveglieri
Il Testing è una pratica sempre più preziosa e fondamentale nell'ambito dello sviluppo del software: si tratta di un passaggio fondamentale per ridurre il numero dei bug nel software e abilitare automatismi come la Continuous Integration e la Continuous Delivery. Se utilizzati in modo errato però, i test possono causare più problemi di quanti ne prevengano: è importante quindi conoscere le differenze tra le varie tipologie di test, quali sono le loro caratteristiche ideali e padroneggiarli al meglio. In questo webinar faremo luce sul Testing, chiariremo bene i concetti di Unit e Integration Test, vedremo come scriverli nel modo corretto e quali tool ci vengono in aiuto... alla fine il Testing non avrà più segreti!
Prepariamoci al cambiamento. ASP.NET MVC e ASP.NET Web API saranno unificati in un unico framework chiamato ASP.NET MVC 6, e questo è solo la prima di una serie di novità che stanno per arrivare.
Tutto si semplifica. Le performance migliorano. Un altro salto tecnologico in avanti portato da ASP.NET 5.
In questa sessione, infatti, vedremo tutte le novità che ASP.NET MVC 6 porta con se, e cercheremo di andare in dettaglio in modo da capire cosa voglia dire realizzare (da zero) o migrare (un'applicazione essitente) a questa nuova versione
ASP.NET Core 2.0 è stato ufficialmente rilasciato e porta con se parecchie novità come le Razor Pages, template aggiornati e l'integrazione con Application Insights migliorata. In questa cercheremo capiremo la vera maturità di questo framework, e quanto questo rilascio sia importante per noi dev.
Dependency injection questa sconosciutaAndrea Dottor
L'uscita di ASP.NET Core ha portato a una maggiore diffusione dell'utilizzo della DI (Dependency Injection) ma spesso senza che lo sviluppatore sappia la sua reale utilità o potenzialità.
Dependency Injection, uno dei design pattern della programmazione OOP. Una best-practice dello sviluppo che può portare alla semplificazione del codice scritto, facilitare il disacoppiamento, e migliorare la testabilità.
In questa sessione vedremo cos'è la DI e come utilizzarla intelligentemente all'interno dei nostri progetti.
Slide dell'evento "XE One Day - Good code" tenuto il 15.09.2018.
Il codice è disponibile alla pagina dell'evento https://www.xedotnet.org/eventi/one-day-good-code/
APPSTUDIO: DA ZERO ALLO STORE IN 50 MINUTI!DotNetCampus
AppStudio e' un ambiente RAD web based per lo sviluppo di Universal App (Windows Phone 8.1 e Windows 8.1) per la visualizzazioni di sorgenti dati. In questa sessione vedremo come sia facile realizzare da zero un'app che acceda a sorgenti remote e come sia, infine, possibile personalizzare il codice sorgente per poter implementare le proprie personalizzazioni.
Disegnare Web Application orientate al Mobile con MVC 4 e jQuery Mobile (We W...Giorgio Di Nardo
Le slide della mia sessione su "Disegnare Web Application orientate al Mobile con MVC 4 e jQuery Mobile" all'evento "We Want Web" organizzato a Roma da "DomusDotNet" in 9 marzo 2012.
Slide della serata post-brainpirlo con l'introduzione al design e allo sviluppo sulla piattaforma Windows Phone 7, a cura di Claudio Gandelli (Looptribe) e Michele Capra (OrangeCode)
Model View Controller - Semplificare Il Codice E Minimizzare I TempiMarco Parenzan
L’aumento della complessità delle applicazioni e la velocità di realizzazione richiesta al giorno d’oggi, hanno obbligato gli sviluppatori ad utilizzare metodologie formali per la scrittura di codice e il successivo testing dello stesso al fine di minimizzare i tempi di rilascio.
L’utilizzo dei pattern, ossia di convenzioni condivise dalla community dei programmatori, è una pratica sempre più diffusa e adottata anche per applicazioni Web.
L’ormai trentennale pattern Model-View-Controller (MVC) sta attualmente conoscendo una nuova giovinezza grazie al successo di framework nelle applicazioni Web che lo usano come riferimento.
Rails è il framework MVC più famoso e diffuso, implementato per la piattaforma Ruby, mentre ASP.NET MVC e MonoRail sono i due framework web MVC che stanno riscuotendo il maggiore successo per lo sviluppo su .NET e su Windows.
Conosceremo quindi la filosofia di riferimento e le specificità dei due framework tramite due implementazioni reali di una stessa applicazione e ne discuteremo vantaggi e svantaggi.
What's New in ASP.NET 4.5 and Visual Studio 2012Andrea Dottor
Slide e codice lo potete trovare a questo link:
http://blog.dottor.net/post/2012/09/18/Codice-e-slide-della-sessione-Whats-New-in-ASPNET-45-and-Visual-Studio-2012.aspx
Il Microsoft .NET Framework è in continua evoluzione, e con la prossima versione verranno rilasciate interessanti funzionalità riguardanti ASP.NET.All'interno di questa sessione conosceremo tutte queste novità, ed andremo invece più in dettaglio in alcune di esse, permettendo a chi conosce già ASP.NET di poter essere più produttivo (Strongly Typed Data Controls, Model Binding, Asynchronous, WebSocket, ... ), mentre, per chi invece non ha molta esperienza con questa tecnologia, potrà vedere come i nuovi template di progetto e Visual Studio 2012 potranno aiutarlo ad approcciare correttamente queste tipologie di applicazioni.
TYPESCRIPT, ANGULAR E BOOTSTRAP ASSIEME PER APPLICAZIONI REAL WORLDDotNetCampus
La recente affermazione in ambito web delle applicazioni rich basate su HTML5 e Javascript è diventato sorgente di una serie di librerie innovative e di strumenti che, se usati correttamente, possono semplificare enormemente lo sviluppo. In questa sessione sarà illustrato come sfruttare Typescript, in concomitanza con Angular e Bootstrap per realizzare applicazioni che sfruttino al massimo le possibilità dei browser e diano un feedback il più possibile simile alle applicazioni desktop.
Gestire l’infrastruttura come se fosse codice, ha degli indubbi vantaggi, soprattutto in un team agile che ha più esperienze Dev piuttosto che Ops.
In questa sessione vi racconteremo la nostra esperienza, problemi, vantaggi e cosa abbiamo imparato.
Lo unified tooling è l’area di interesse DevOps che fonde pratiche di software development a quelle di system administration, con lo scopo di semplificare il processo di deployment di ambienti complessi. In questo talk vengono esposte le esperienze di un team di dev che è riuscito a gestire e replicare ambienti complessi, ricorrendo a strumenti e pratiche delle metodologie agili. Saranno evidenziati i vantaggi ottenuti e le problematiche riscontrate.
NET Framework versione 4 include miglioramenti per ASP.NET 4 in aree mirate. Anche Visual Studio 2010 include miglioramenti e nuove funzionalità per ottimizzare lo sviluppo di risorse Web. In questa sessione verrà fornita una panoramica di numerose delle nuove funzionalità incluse nella nuova versione. Vedremo anche le novità per gli sviluppatori introdotte da Internet Explorer 9
This set of design patterns are related to Enterprise Patterns. In it you can find, J2EE, Presentation, Business & Integration Patterns (such as: ApplicaCon Controller, Data Transfer Object (DTO), Business Object (BO) & Data Access Object (DAO) among others ...)
In questa serata cercheremo di capire perchè Blazor ha riscosso così tanto successo, e lo faremo analizzando casi presi da applicazioni reali dove questa tecnologia è stata introdotta, così da capirne meglio le potenzialità (ma anche le eventuali criticità).
Come di consuetudine, faremo poi un confronto, così da condividere i vari punti di vista.
ASP.NET 4.6 e ASP.NET 5...l'evoluzione del webAndrea Dottor
Una sessione alla scoperta delle grandi novità che ASP.NET 5 introduce. Questo nuovo aggiornamento del framework non porta solo un'evoluzione alla tecnologia che già conosciamo, ma porta importanti e radicali cambiamenti (una "rivoluzione" di molte cose che già conosciamo e utilizziamo) che dobbiamo essere pronti a sfruttare il prima possibile per dare una marcia in più alle nostre applicazioni. ASP.NET MVC 6, nuovo template di progetto, cross-platform.
Blazor è un framework per la creazione di Single Page Application (SPA) tramite l’utilizzo di C#.
Creato da Steve Sanderson e successivamente inserito in .NET Core come esperimento.
Visto l’enorme successo avuto sulla community è stato poi deciso di renderlo parte integrante dell’ecosistema .NET
Offre tutti i vantaggi di un framework front-end scrivendo codice interamente in C#.
OVERVIEW: Java secondo Microsoft
STRUMENTI:Java nel cloud
MODALITA’: Il Development life cycle secondo Microsoft
APPROCCIO: Stack cloud native basato su JAVA ed Azure
CAMBIAMENTO: Know how necessario per lo sviluppo su AZURE con Java
OPPORTUNITA: Use case di implementazione «first approach»
1. ASP.NET MVC:
Andare oltre il 100%
Giorgio Di Nardo
Proge-Software s.r.l.
giorgio.dinardo@domusdotnet.org
@akelitz
http://blogs.ugidotnet.org/akelitz
Web@Work
4. Web@Work
NuGet
Aggiungere un riferimento Aggiungere un riferimento
senza NuGet con NuGet
Trovarlo
Scaricarlo
Estrarlo
Aggiungere
pacchetto
Referenziarlo
Configurarlo
5. Web@Work
NuGet
• Un Package Manager per .NET e Visual
Studio
• Installabile tramite Extension Manager
• Utilizzabile tramite:
• GUI
• Console PowerShell
• Tool a riga di comando
• Supporta sorgenti multiple (pubbliche e
private)
6. Ciclo di vita di una richiesta Web@Work
con ASP.NET MVC
Model
Request Action Response
Binder
URL Action
Controller View
Routing Filter
HTTP Controller Action View
Handler Factory Result Engine
7. Web@Work
Localizzazione
• Processo attraverso il quale è possibile
fornire il contenuto della nostra
applicazione in diverse lingue senza
dover riscrivere tutto
• Tipicamente ottenuto per mezzo di file di
risorsa tradotti nelle varie lingue da
supportare
• Disponibile out-of-the-box con ASP.NET
12. Web@Work
Dependency Resolver
• Consente di risolvere i problemi di
dipendenza
• Concretizzazione del pattern astratto
Inversion-of-Control (IoC)
• Permette di incapsulare facilmente uno IoC
Container
• Molte implementazioni disponibili su NuGet
13. Web@Work
Dipendenze e IoC
• Il componente A da passivo (subisce la
scelta di B di usare C)...
Componente Componente Servizio
A B C
• ...diventa attivo (impone a B di usare D
per svolgere un azione di tipo IC)
Componente Servizio Componente
A D : IC B
16. Web@Work
Service Locator
• Il pattern Service Locator implementa
l’astrazione di IoC definendo un
componente esterno responsabile della
risoluzione delle dipendenze
• Un Service Locator può essere:
• Specifico: consente la risoluzione strongly
typed di interfacce ben definite
• Generico: fornisce un approccio generico per
la risoluzione di qualunque tipo di dipendenza
18. Web@Work
SL specifici: pregi e difetti
• È facile da capire e utilizzare
• Consente di personalizzare la creazione
degli oggetti usando parametri
• È limitato alla creazione degli oggetti
previsti in fase di design
• Rischia di trasformare la sua
manutenzione in un incubo
20. Web@Work
SL generici: pregi e difetti
• Risolve ogni tipo di dipendenza anche
senza conoscere il tipo di oggetto
richiesto
• Riduce i costi di manutenzione, non
richiedendo la modifica dell’interfaccia
• Non fornisce informazioni qualitative sui
servizi che eroga (o che non eroga)
• Non consente di personalizzare la
creazione degli oggetti restituiti
21. Web@Work
Dependency Injection
• Implementazione di IoC basata sulla
realizzazione dei componenti in modo tale
da consentire un’esplicità indicazione
delle dipendenze dall’esterno
• Rispetto a SL consente una trasparenza
del codice nettamente maggiore
• Può essere declinata in due varianti:
• Constructor Injection
• Property Injection
22. Web@Work
DI: Constructor Injection
• Forma più comune di Dependency
Injection
• Il costruttore del componente specifica
esplicitamente tutte le sue dipendenze
• Il componente non deve conoscere i
dettagli di funzionamento del Service
Locator
• L’utilizzo del componente è chiaro con un
semplice sguardo al costruttore
23. Web@Work
DI: Property Injection
• Forma meno comune di Dependency
Injection
• Le dipendenze possono essere iniettate
impostando proprietà apposite
• È meno chiaro che prima di utilizzare un
metodo del componente bisogna settare una
proprietà
• Consente di specificare dipendenze
opzionali
• Unica scelta se non si può gestire la
chiamata al costruttore
24. Web@Work
Dependency Injection Containers
• Entrambi i metodi dicono «cosa» fare ma
non «come» farlo: la risposta è nei DI
Container
• Sono librerie che agiscono come Factory
dei componenti analizzando
automaticamente le dipendenze
• Simili nell’aspetto esterno ai SL si
prendono però carico anche della
creazione dell’oggetto da restituire
26. Web@Work
Testing, Unit testing e TDD
• Parte dello sviluppo software che si
occupa della verifica delle corrispondenza
tra il funzionamento del codice e i requisiti
• Unit testing, integration
testing, performance testing, scalability
testing
• Consente di migliorare la qualità del
proprio codice, ridurre il peso della
manutenzione ma anche (TDD)
migliorarne il design
27. Web@Work
Pilastri dello Unit testing
• Testare piccoli frammenti di codice
(«unit»), tipicamente metodi
• Testare in maniera isolata rispetto al resto
dell’applicazione
• Testare i soli endpoint pubblici
• Ottenere il risultato positivo/negativo dei
test in maniera automatizzata
28. Web@Work
Test Driven Design
• Utilizzare lo Unit testing per guidare lo
sviluppo della propria applicazione
• Scrivere il codice strettamente necessario
a passare i test
• Red/Green cycle
• Utilizzabile sia per i nuovi sviluppi che per
il bug fixing
• Attenzione al refactoring!
29. Web@Work
Arrange, Act, Assert
• Arrange: predisporre l’ambiente per il test
• Act: effettuare la chiamata al codice
oggetto del test
• Assert: verificare che ciò che ci si
aspettava si è verificato (e ciò che non ci
si aspettava non si è verificato)
• Verificare un comportamente alla volta
(single assertion rule)
Possibilità di far fare al metodocose diverse (sms, email, ecc.)Possibilità di testareilmetodo
The service locator pattern says that inversion of control is achieved by having components get theirdependencies through an external component known as the service locator. Sometimes a servicelocator is a very specific interface, with strongly typed requests for specific services, and sometimesit may show up as a very generic way to request services of any arbitrary type.
In this case, when you need an implementation of IServiceLocator, you know to callGetMessageSender. The method returns exactly IMessageSender, so you won’t need to castthe result.You’ll notice that I’m showing the service locator as an interface here rather than as a concrete type.Remember that one of your goals is to reduce the tight coupling between components; this includesthe coupling between the consumer code and the service locator itself. If the consumer code is codedagainst IServiceLocator, that means you can substitute alternative implementations at run time asappropriate. This can have tremendous value in unit testing.Now if you re-write NotificationSystem in terms of the strongly typed service locator, it mightlook like this.We’re assuming that anybody who creates an instance of NotificationSystem will haveaccess to a service locator.
public interface IServiceLocator{IMessagingService GetMessagingService();}
In this case, when you need an implementation of IServiceLocator, you know to callGetMessageSender. The method returns exactly IMessageSender, so you won’t need to castthe result.You’ll notice that I’m showing the service locator as an interface here rather than as a concrete type.Remember that one of your goals is to reduce the tight coupling between components; this includesthe coupling between the consumer code and the service locator itself. If the consumer code is codedagainst IServiceLocator, that means you can substitute alternative implementations at run time asappropriate. This can have tremendous value in unit testing.Now if you re-write NotificationSystem in terms of the strongly typed service locator, it mightlook like this.We’re assuming that anybody who creates an instance of NotificationSystem will haveaccess to a service locator.
Why might you choose a weakly typed locator? It allows you to fi x many of the downsides of thestrongly typed locator; that is, you get an interface that can create arbitrary types without knowingabout them ahead of time, and it reduces your maintenance burden because the interface is not constantlyevolving.On the other hand, a weakly typed locator interface doesn’t really communicate anything aboutthe kinds of services that might be requested, and it doesn’t offer a simple way to customize the creationof the service. You could add an arbitrary optional array of objects as “creation parameters”
Non è il componente che cerca verso l’esterno un servizio che risolva le dipendenze ma è la chiamata dall’esterno che fornisce al componente la risoluzione delle dipendenze.The dependency injection (DI) pattern is another form of the inversion of control pattern, whereinthere is no intermediary object like the service locator. Instead, components are written in a waythat allows their dependencies to be stated explicitly, usually by way of constructor parameters orproperty setters.Developers who choose dependency injection over service location are often making a consciousdecision to choose transparency of requirements over opacity. Choosing the transparency of dependencyinjection also has signifi cant advantages during unit testing, as discussed in the next chapter.
The most common form of dependency injection is called constructor injection. This techniqueinvolves creating a constructor for your class that expresses all of its dependencies explicitly (asopposed to the previous service location examples, where your constructor took the service locatoras its only constructor parameter).In this code, the fi rstbenefi t is that the implementation of the constructor is dramatically simplifi ed.The component is always expecting whoever creates it to pass the required dependencies. It onlyneeds to store the instance of IMessagingService for later use.Another benefi t is that you’ve reduced the number of things NotificationSystem needs to knowabout. Previously, it needed to understand service locators in addition to its own dependencies; now,it is focused solely on its own dependencies.The third benefi t, as alluded to previously, is this new transparency of requirements. Any code thatwants to create an instance of NotificationSystem can look at the constructor and know exactlywhat kinds of things are necessary to make NotificationSystem function. There is no guessworkand no indirection through the service locator.
A less common form of dependency injection is called property injection. As the name implies,dependencies for a class are injected by setting public properties on the object rather than throughthe use of constructor parameters.This class expects any consumers to provide you with your dependenciesvia properties rather than the constructor.The InterestingEventHappened method is now slightly dangerous. It presumes that the servicedependency has already been provided; if it hasn’t, then it will throw a NullReferenceException.You should update the InterestingEventHappened method to ensure that it has been providedwith its dependency before using the service.It should be obvious that you’ve slightly reduced your transparency of requirements here; it’s not quiteas opaque as using the service locator, but it’s definitely more error prone than constructor injection.With this reduced transparency, you’re probably wondering why a developer would choose propertyinjection over constructor injection. Two situations might warrant that choice:‰ If your dependencies are truly optional in the sense that you have some fallback when theconsumer doesn’t provide you with one, property injection is probably a good choice.‰ Instances of your class might be created in such a way that you don’t have control over theconstructor that’s being called. This is a less obvious reason. You’ll see a couple of examplesof this later in the chapter when we discuss how dependency injection is applied to view pages.In general, developers tend to favor using constructor injection whenever possible, falling back toproperty injection only when one of the preceding reasons dictates. Obviously, you can mix bothtechniques in a single object: put your mandatory dependencies in as constructor parameters, andyour optional dependencies in as properties.
A dependency injection container is a software library that acts as a factory for components,automatically inspecting and fulfilling their dependency requirements.The consumption portion of theAPI for a dependency injection container looks a lot like a service locator because the primary actionyou ask it to perform is to provide you with some component, usually based on its type.The difference is in the details, of course. The implementation of a service locator is typically verysimple: You tell the service locator, “If anybody asks for this type, you give them this object.”Service locators are rarely involved in the process of actually creating the object in question. Adependency injection container, on the other hand, is often configured with logic like, “If anybodyasks for this type, you create an object of this concrete type and give them that.” The implication isthat creating the object of that concrete type will, in turn, often require the creation of other typesto fulfill its dependency requirements. This difference, while subtle, makes a fairly large differencein the actual usage of service locators versus dependency injection containers.
A dependency injection container is a software library that acts as a factory for components,automatically inspecting and fulfilling their dependency requirements.The consumption portion of theAPI for a dependency injection container looks a lot like a service locator because the primary actionyou ask it to perform is to provide you with some component, usually based on its type.The difference is in the details, of course. The implementation of a service locator is typically verysimple: You tell the service locator, “If anybody asks for this type, you give them this object.”Service locators are rarely involved in the process of actually creating the object in question. Adependency injection container, on the other hand, is often configured with logic like, “If anybodyasks for this type, you create an object of this concrete type and give them that.” The implication isthat creating the object of that concrete type will, in turn, often require the creation of other typesto fulfill its dependency requirements. This difference, while subtle, makes a fairly large differencein the actual usage of service locators versus dependency injection containers.
A dependency injection container is a software library that acts as a factory for components,automatically inspecting and fulfilling their dependency requirements.The consumption portion of theAPI for a dependency injection container looks a lot like a service locator because the primary actionyou ask it to perform is to provide you with some component, usually based on its type.The difference is in the details, of course. The implementation of a service locator is typically verysimple: You tell the service locator, “If anybody asks for this type, you give them this object.”Service locators are rarely involved in the process of actually creating the object in question. Adependency injection container, on the other hand, is often configured with logic like, “If anybodyasks for this type, you create an object of this concrete type and give them that.” The implication isthat creating the object of that concrete type will, in turn, often require the creation of other typesto fulfill its dependency requirements. This difference, while subtle, makes a fairly large differencein the actual usage of service locators versus dependency injection containers.
A dependency injection container is a software library that acts as a factory for components,automatically inspecting and fulfilling their dependency requirements.The consumption portion of theAPI for a dependency injection container looks a lot like a service locator because the primary actionyou ask it to perform is to provide you with some component, usually based on its type.The difference is in the details, of course. The implementation of a service locator is typically verysimple: You tell the service locator, “If anybody asks for this type, you give them this object.”Service locators are rarely involved in the process of actually creating the object in question. Adependency injection container, on the other hand, is often configured with logic like, “If anybodyasks for this type, you create an object of this concrete type and give them that.” The implication isthat creating the object of that concrete type will, in turn, often require the creation of other typesto fulfill its dependency requirements. This difference, while subtle, makes a fairly large differencein the actual usage of service locators versus dependency injection containers.
A dependency injection container is a software library that acts as a factory for components,automatically inspecting and fulfilling their dependency requirements.The consumption portion of theAPI for a dependency injection container looks a lot like a service locator because the primary actionyou ask it to perform is to provide you with some component, usually based on its type.The difference is in the details, of course. The implementation of a service locator is typically verysimple: You tell the service locator, “If anybody asks for this type, you give them this object.”Service locators are rarely involved in the process of actually creating the object in question. Adependency injection container, on the other hand, is often configured with logic like, “If anybodyasks for this type, you create an object of this concrete type and give them that.” The implication isthat creating the object of that concrete type will, in turn, often require the creation of other typesto fulfill its dependency requirements. This difference, while subtle, makes a fairly large differencein the actual usage of service locators versus dependency injection containers.
