{"id":29381,"date":"2020-12-09T00:00:00","date_gmt":"2020-12-08T23:00:00","guid":{"rendered":"https:\/\/blexin.com\/?p=29381"},"modified":"2021-01-13T09:39:54","modified_gmt":"2021-01-13T08:39:54","slug":"benvenuto-net-5","status":"publish","type":"post","link":"https:\/\/blexin.com\/it\/blog\/benvenuto-net-5\/","title":{"rendered":"Benvenuto .NET 5"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Da circa tre mesi sono entrato nel team Blexin ed ho avuto la fortuna di partecipare ad un progetto in fase di startup. Il Cliente ci chiede la riscrittura di un applicativo WPF creato per lavorare offline con meccanismi di sincronizzazione dei dati con una versione Web e quindi accesso ai dati in tempo reale.<\/p>\n\n\n\n

La richiesta \u00e8 arrivata in concomitanza con il rilascio di .NET 5 e con il team abbiamo deciso di approfondire, in questo progetto, le novit\u00e0 introdotte sul campo ed ho pensato potessero essere utili a chi sta pensando ad una migrazione simile.<\/p>\n\n\n\n

Vediamo quindi insieme le principali novit\u00e0 che Microsoft ha presentato il 10 Novembre alla .NET Conference e come si stia evolvendo il framework.<\/p>\n\n\n\n

Nelle intenzioni di Microsoft c\u2019\u00e8 sempre stata l\u2019idea di rendere possibile scrivere codice riutilizzabile (librerie) su pi\u00f9 piattaforme (Web, Mobile, Desktop, IoT, Cloud e chi pi\u00f9 ne ha pi\u00f9 ne metta) e, nonostante .NET 5 sia un passo decisivo in quella direzione, la roadmap attuale ci dice che sar\u00e0 .NET 6 a completare il processo.<\/p>\n\n\n\n

La storia degli ultimi 20 anni \u00e8 disseminata da tentativi, non sempre riusciti (leggi: Silverlight), di convergenza tra ambienti eterogenei. Facciamo un piccolo ripasso insieme di questi tentativi, perch\u00e9 dalla storia e dagli errori si deve sempre imparare.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Nel dicembre del 2006, grande fu la sorpresa per tutti gli sviluppatori Windows Form all\u2019annuncio della versione beta di Silverlight: un plugin da installare sul browser che permetteva di far \u201cgirare\u201d codice C# all\u2019interno del browser stesso.<\/p>\n\n\n\n

Varie versioni sono state rilasciate nel tempo, aumentando le funzionalit\u00e0 e la percentuale di codice che, potenzialmente, si poteva condividere. Ho sperimentato un paio di progetti con la versione 3.0 nel 2010, e devo dire che le premesse per un buon risultato c\u2019erano tutte, con tanto di editor avanzato per la grafica e pattern MVVM nativo. Purtroppo, la dipendenza da un plugin esterno non fu accolto dal mercato positivamente che non ne colse le potenzialit\u00e0. Oggi Silverlight \u00e8 arrivato alla versione 5 e il supporto terminer\u00e0 ad ottobre 2021.<\/p>\n\n\n\n

Poi venne Xamarin, un\u2019applicazione del framework Mono, il porting di .NET Framework su piattaforma Linux, Android, Mac OS e IOS. Ricordo la mia gioia quando, durante la conferenza Build del 2016, ci fu l\u2019annuncio dell\u2019acquisizione di Xamarin da parte di Microsoft e la disponibilit\u00e0, a partire da Visual Studio 2017, di tutto il pacchetto Xamarin per lo sviluppo cross platform per i sistemi operativi mobile IOS, Android e Universal Windows Platform. Considerate che all’epoca Microsoft si considerava ancora un competitor per sistemi operativi Mobile ed aveva appena rilasciato Windows 10 Mobile. Il meccanismo che introdusse Xamarin per condividere il codice tra i vari ambiente fu duplice: Shared Project e Portable Class Library. La differenza tre le due implementazioni consisteva nella conoscenza dell\u2019ambiente di deploy e delle relative primitive: nello Shared Project era possibile invocare metodo esclusivi della piattaforma di riferimento, mentre nella le Portable Class Library esisteva un subset di primitive comuni a tutte le piattaforme.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Le Portable Class Library sono state il seme che ha dato vita al progetto .Net Standard: un contratto di funzionalit\u00e0 comuni a cui le varie implementazioni del framework (.net Framework 4.x, .Net Core, Mono) si sottoscrivono. In fase di compilazione, viene referenziata l’implementazione opportuna per l’ambiente per cui si sta compilando.<\/p>\n\n\n\n

Un grande lavoro \u00e8 stato dedicato ai runtime coreFx e Mono, introducendo il supporto per Windows ARM64 e non solo. Consapevole dell\u2019importanza che ricopre la containerizzazione, un impegno significativo in questa direzione da parte di Microsoft ha portato alla riduzione delle dimensioni delle immagini docker.<\/p>\n\n\n\n

Con l\u2019arrivo di .NET 5 le librerie hanno adesso un\u2019implementazione di tutte le funzionalit\u00e0 su ogni runtime, mentre il progetto di unificazione della UI App di avere un unico progetto che in fase di compilazione venga \u201ctipizzato\u201d per l\u2019ambiente di deploy, cos\u00ec come avviene per le librerie, \u00e8 rimandato al prossimo anno. Per chi volesse cominciare a dare uno sguardo, qui trovate il link al repository del progetto MAUI<\/a>.<\/p>\n\n\n\n

Ma vediamo come tutte queste novit\u00e0 ci aiutano nel quotidiano e nel refactoring che stiamo affrontando.<\/p>\n\n\n\n

Cominciamo con la memorizzazione dei dati: Entity Framework sia nella versione full framework che Core \u00e8 supportato in .NET 5. Questo significa che anche librerie un po\u2019 datate, di cui non si \u00e8 pensato di fare il refactoring, scritte utilizzando Entity Framework 6.x, sono riutilizzabili. Ma EF Core 5, con la riscrittura totale di tutto il motore, ha un impatto significativo sulle performance, aspetto che non pu\u00f2 essere trascurato nella scelta.<\/p>\n\n\n\n

Tra le novit\u00e0 introdotte le pi\u00f9 rilevanti sono sicuramente il mapping many-to-many delle tabelle (finalmente!) ed il supporto al logging configurabile con il metodo LogTo <\/strong>presente nel classe DbContextOptionsBuilder.<\/strong><\/p>\n\n\n\n

Il framework .NET 5 supporta tutte le novit\u00e0 introdotte dai linguaggi C# 9 e F# 5. Per i dettagli, se ve lo foste perso, vi consiglio l\u2019articolo<\/a> di Francesco.<\/p>\n\n\n\n

Per il mondo servizi, le novit\u00e0 pi\u00f9 consistenti introdotte in ASP.NET Core 5 riguardano il supporto a HTTP\/2 e gRPC, che vanno a colmare il vuoto lasciato dall\u2019assenza di WCF, che ci lascia definitivamente.<\/p>\n\n\n\n

Per quando riguarda il mondo front-end Web server side, il supporto ai tipi record in Razor e il supporto nativo a Swagger sono sicuramente gli aspetti pi\u00f9 interessanti. L\u2019utilizzo dei record nel model binding ha sicuramente un impatto positivo sulla memoria e quindi anche sulle performance, mentre chi come me trova in Swagger uno strumento indispensabile si ritrova questa libreria nativamente nei propri progetti.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Assoluto protagonista di questo rilascio \u00e8 sicuramente Blazor, che raggiunge la sua maturit\u00e0 con le novit\u00e0 introdotte da .NET 5 (qui trovate una guida introduttiva<\/a> del nostro CEO\/CTO Michele Aponte), con incremento delle performance, riduzione del payload del primo accesso e una serie di funzionalit\u00e0 quali:<\/p>\n\n\n\n