Asp.net vNext è il nome della prossima versione di Asp.net. Questa nuova versione abbraccia completamente l'interfaccia OWIN ed elimina l'annosa dipendenza da System.Web. Queste due condizioni rendono ASP.NET completamente indipendente dall'host e quindi possiamo hostare i nostri siti non solo più su IIS, IISExpress, Cassini, ma anche su applicazioni console e su altri host che adottano OWIN. Il risultato è che le applicazioni ASP.NET possono girare anche su MAC (ok quest'ultima affermazione non è che mi faccia granché effetto, ma ho visto gente avere quasi un infarto dalla gioia quando ho spiegato questa cosa).
Oltre a queste caratteristiche che rendono ASP.NET vNext interessante. La principale è che ASP.NET vNext smette di essere il monolite che è adesso ASP.NET. D'ora in poi tutto sarà su NuGet. Tutti gli assembly di ASP.NET verranno scaricati da NuGet come qualunque altra libreria. Il bello è che non essendoci più il monolite, ogni funzionalità verrà creata in assembly a parte che verranno referenziati dallo sviluppatore solo quando quella funzionalità gli serve. Questo comporta grossi vantaggi in termini di velocità di startup dell'applicazione in quanto il numero di assembly da caricare aumenta rispetto al monolite, ma essendo gli assembly molto limitati nelle dimensioni (in quanto contengono solo una o poche funzionalità) la velocità del caricamento è elevatissima. Un altro vantaggio di questa nuova filosofia è che anche il .NET Framework può essere distribuito insieme all'applicazione quando dobbiamo creare il pacchetto di deploy. In questo modo la nostra applicazione non ha dipendenze da altro che non sia nella bin (F I G A T A).
Come sempre, non è tutto oro quel che luccica. Alzi virtualmente la mano chi non ha avuto problemi con NuGet... Ok, intuisco che nessuno la sta alzando. NuGet è stupendo, ma fin troppe volte mi sono trovato in condizioni difficili. Nuove versioni di package che rompevano comportamenti esistenti di altri package. Package che vanno in conflitto con la versione in uso di altri package, e molto altro ancora. Insomma il succo è: tutto bello, ma la distribuzione tramite NuGet mi fa storcere il naso e preoccupare non poco.
Comunque, guardando avanti c'è un'altra cosa che mi piace: La compilazione a run time. Ricordate la compilazione tramite Code File introdotta con ASP.NET 2.0? Beh, io la adoravo. Finalmente potremo avere una cosa del genere ovunque, anche per MVC. Deployamo il codice dei controller e questo viene compilato a run time. Se dobbiamo modificare un file cambiamo solo quello e via. Ovviamente abbiamo sempre la possibilità di precompilare tutto come adesso, ma posso dire che deployare il codice sorgente non è un problema nel 99% dei casi e i benefici sono notevoli. Ok, capisco la proprietà intellettuale e la paura dei furti di codice, ma in 15 anni ho avuto questo problema una sola volta.
In conclusione, ASP.NET vNext mi piace e anche tanto, ma quella paura di ritrovarmi in un reference hell per via del numero elevato di package, versioni e dipendenze su NuGet mi rimane... Staremo a vedere.
Stay tuned...
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
- Entity Framework è lento! mmmmh, probabilmente sei tu che lo stai usando male!, il 7 ottobre 2022 alle 10:55
- E così AngularJS e DurandalJS convergono..., il 7 maggio 2014 alle 11:51
- Usare fiddler per simulare le risposte da un servizio, il 28 ottobre 2013 alle 08:00
- Tip: cosa fare quando Entity Framework Code-First Migrations smette di funzionare, il 18 gennaio 2013 alle 11:04
- Visual Studio 11 beta: le novità di Entity Framework 5.0 e WCF 4.5, il 2 marzo 2012 alle 23:08