TOC

This article is currently in the process of being translated into Italian (~99% done).

Introduzione:

ASP.NET MVC vs. Web Forms

La prima versione di ASP.NET è stata rilasciata nel 2002, e l'unico view engine disponibile era Web Forms. Più avanti, per supportare tecnologie come MVC, Microsoft ha esteso ASP.NET per supportare più view engine, ma per molti anni, usare ASP.NET implicava usare anche Web Forms.

Per i Web Forms, Microsoft aveva un obiettivo molto importante: voleva astrarre il più possibile i dettagli complessi del protocollo HTTP e la sua natura stateless e rendere lo sviluppo web il più possibile simile allo sviluppo di applicazioni Windows, che al tempo era già un'esperienza piuttosto piacevole.

La soluzione fu l'introduzione del ViewState, che avrebbe assicurato che lo stato di ogni form venisse preservato tra i vari post back effettuati verso il server, e dei server control, che incapsulavano il rendering di HTML e CSS dentro a un componente arbitrario che poteva essere configurato tramite le sue proprietà invece di forzare lo sviluppatore a mescolare direttamente HTML e CSS.

Inoltre venne introdotto un modello basato a eventi, già conosciuto al tempo dagli sviluppatori Windows, per permettere allo sviluppatore di rispondere ad eventi, quali un bottone che veniva cliccato o un checkbox che cambiava stato, invece di effettuare controlli manuali ogni volta che la pagina veniva ricaricata. Questo tra l'altro significava che il markup e il codice di backend erano separati, che in teoria è una buona idea.

Dove hanno fallito i Web Forms

I Web Forms sono stati una boccata di aria fresca per molti sviluppatori, è probabilmente hanno anche aiutato molti nuovi sviluppatori, o sviluppatori abituati allo sviluppo di applicazioni Windows, ad imparare le tecniche per creare applicazioni web. Sfortunatamente, Microsoft non è riuscita a creare una astrazione perfetta, infatti iniziarono ad emergere rapidamente molti problemi. Alcuni furono corretti in rilasci successivi, ma molti altri erano alla base del funzionamento dei WebForms e quindi erano più difficili da modificare. La tecnologia Web Forms è stata criticata principalmente per i seguenti motivi:

La ViewState rende le pagine più 'pesanti'

Tenere traccia di ogni singolo controllo presente sulla pagina nella stringa del ViewState; la quale è spedita avanti e indietro tra il server ed il client ad ogni richiesta; rende le pagine dei Web Forms piuttosto pesanti in termini di dati trasmessi. Se stai costruendo una pagina dalla complessità media, la ViewState risultante può causare un incremento del traffico di diversi kilobytes. Ciò può comportare tempi di caricamento più lunghi, specialmente sulle connessioni mobile e, con l'incremento del traffico causato dagli smartphones in tutto il mondo, questo è diventato un problema molto reale

I Controlli lato server limitano la tua capacità di controllare l'output HTML

I controlli lato server rendono facile la creazione veloce di qualcosa di utile, ma non ti daranno mai il pieno controllo del testo HTML da loro creato. Ciò diventa un problema quando hai la necessità di controllare accuratamente il tuo lavoro e altrettanto se scopri qualche problema di compatibilità tra i browser.

Web Forms non è adatto per i test automatici

I Web Forms furono introdotti prima che i test automatici diventassero così importanti e, quando lo divennero, fu abbastanza chiaro che con i Web Forms era molto difficile, se non impossibile, effettuare degli unit test efficaci

Dove ASP.NET MVC è un miglioramento rispetto ai Web Forms

ASP.NET MVC elimina gran parte delle astrazioni implementate dai Web Forms. Per esempio, di solito tutto il testo HTML deve essere generato da te, invece di affidarsi ai controlli lato server. Non esiste più una ViewState gestita dal sistema per te, si elimina quindi il problema, ma, allo stesso tempo, diversi controlli lato server, come la GridView ed il Repeater, diventano inutili.

Il modello MVC è perfetto per i test automatici, a causa dell'accoppiamento non stretto fra i differenti strati software.

Quale tecnologia dovresti scegliere?

E' importante ricordare che, durante la lettura del presente capitolo, i Web Forms possono apparire come una tecnologia antiquata, ma in realtà non lo sono affatto - i Web Forms sono ancora in una fase di sviluppo attivo da parte di Microsoft e sono ancora una scelta possibile quando si inizia a sviluppare per il mondo Web usando ASP.NET. I Web Forms sono specialmente adatti per quelle situazioni in cui vorreste qualcosa pronto molto rapidamente - la grande quantità di controlli lato server consente di realizzare facilmente qualcosa di utile e di fretta, al prezzo della flessibilità che avreste se scrivete tutto il markup della pagina manualmente.

Se conoscete già come usare i Web Forms, dovreste assolutamente provare ad usare ASP.NET MVC, specialmente se alcuni dei problemi indicati in precedenza stanno effettivamente creando delle difficoltà. Se invece siete all'inizio dello sviluppo web e dovete decidere fra le due tecnologie, vi raccomanderei comunque di provare ASP.NET MVC. Il modello MVC potrebbe sembrare un pò restrittivo ad alcune persone, e dover seguire un pattern, è ovviamente più difficile all'inizio piuttosto che non seguirne alcuno, ma una volta che ci si abitua, è molto piacevole lavorarci e, in generale, a giudicare dall'attenzione che il modello MVC riceve, non penso che sparirà molto presto.

Sommario

Così, mentre ASP.NET Web Forms potrebbe essere un pò più facile per iniziare, probabilmente, se iniziate ora a sviluppare per il mondo Web, dovreste provare prima ad usare ASP.NET MVC. Non preoccupartevi, questa guida vi aiuterà a partire e vi piloterà attraverso il processo di sviluppo della vostra prima applicazione ASP.NET MVC.


This article has been fully translated into the following languages: Is your preferred language not on the list? Click here to help us translate this article into your language!