ASP.NET: WebForms vs MVC
Quanto Microsoft, nel lontano 2009, ha rilasciato ASP.NET MVC, mi sono chiesto il motivo per cui è stato
scelto di mettere a disposizione un framework web che affiancasse ASP.NET WebForms. Ad una prima occhiata
non sono riuscito a vedere i vantaggi della nuova tecnologia, rispetto ad un'altra, solida, ben collaudata
e diffusa come WebForms.
E' da sottolineare che il grande merito di quest'ultima, all'inizio del nuovo millennio, è stato avvicinare una massa di sviluppatori desktop (la maggior parte dei quali legati al buon vecchio Visual Basic 6.0), al mondo web. Il paradigma di programmazione che veniva proposto - nella sua semplicità concettuale - era geniale: simulare il modello "ad eventi" (tipico dei desktop, appunto) applicato al web.
La magia realizzata da "postback" e "viewstate" ha quindi permesso, solo con l'introduzione di qualche nuovo concetto, di aumentare esponenzialmente il numero di web-developers Microsoft, quindi iniettare nuova linfa produttiva nelle vene di Internet, che proprio in quegli anni ha conosciuto il suo grande boom.
Nell'immaginario collettivo, WebForms, è sempre stato sinonimo di grande produttività, con tempi di sviluppo ridotti, e buona qualità del prodotto finale; anche per sviluppatori con una conoscenza non approfondita delle problematiche legate al web.
Per quasi un decennio, WebForms, ha rappresentato l'unico modo di fare "web" su .NET. Ma non tanto una "scelta obbligata": semplicemente perchè non si è mai effettivamente sentita la necessità di cercare altre vie, poichè le esigenze degli utenti non sono cambiate così radicalmente da giustificare una vera rivoluzione. Con i vari framework e service packs, sono state rilasciate implementazioni che hanno sempre più semplificato la vita dello sviluppatore migliorando la qualità del prodotto finale; ma le basi su cui costruire tutta l'intelaiatura è rimasta sostanzialmente la stessa.
Ma negli ultimi 4-5 anni, con la diffusione di Internet in mobilità, e l'introduzione sul mercato di numerosi device caratterizzati da specifiche eterogenee, hanno iniziato a sentirsi sempre più forti i temi del "controllo" sull'output generato, quello della "ottimizzazione" dei dati sul canale e, non ultimo, quello della sicurezza sui dati.
Benchè "WebForms", nelle sue ultime versioni, rispondesse efficacemente a queste nuove problematiche - e vi risponde tutt'ora - è evidente che la produttività, che rappresentava il punto di forza di questo framework, tende a venire un po' se si da molta importanza a queste problematiche. Le "best practices" da mettere in atto per ottimizzare il dialogo client-server e migliorare l'output di uscita, sono molteplici; e molte di esse richiedono delle conoscenze approfondite sia del protocollo HTTP, che di WebForms stesso.
Altra importantissimo aspetto che non va sottovalutato è come la rete sia diventata sempre più "orientata ai servizi" e meno alle applicazioni "chiavi in mano". Molti device fruiscono Internet utilizzando applicazioni native, che sfruttano la rete con il solo scopo di attingere dati nudi e crudi (in formato JSON o XML), demandando la parte di interazione utente e "presentation" a dei moduli locali (le "App").
Da questo punto di vista, a mio parere, ASP.NET MVC ha qualche cosa in più. Diversamente da WebForms, che tende a simulare un ambiente state-full usando viewstate e postback, l'incarnazione Microsoft di Model-View-Controller abbraccia completamente la natura state-less del protocollo HTTP, e sfrutta le specifiche sulle quali è stato concepito fino all'ultima risorsa.
Si ha un controllo completo sull'output emesso per la renderizzazione client (diversamente da WebForms, che viene "infarcito" di strutture atte a preservare lo stato della pagina). E' possibile gestire granularmente l'accesso alla singola risorsa ("Action") verificando i parametri in ingresso nella "request", e fornendo un'adeguata "response". Non ultimo, la natura modulare con cui è stato concepito ASP.NET MVC, va nell'ottica di realizzare applicazioni altamente testabili e maggiormente manutenibili. Ogni singola porzione applicativa (detta anche "unità") può beneficiare della filosofia con cui il sistema è stato concepito il sistema, il "SoC" (Separation of Concerns), e una struttura organizzativa di progetto che rende semplice intervenire chirurgicamente sul sistema anche in fase di maintenance.
Va comunque detto che MVC, usato in maniera del tutto "nativa", è piuttosto ostico da apprendere ed applicare; ma usandolo in combinazione con dei framework client side (cito solo "KnockoutJs", "DurandalJs" o "AngularJs") rappresenta una vera macchina da guerra. Applicazioni prima immaginabili solo in ambiente desktop, sono realtà pubblicate sulla rete; ed MVC è il perfetto backend per incorporare tutta la potenza "server-side" di questi applicativi.
Chiaramente il tema "WebForms vs MVC" è tutt'ora aperto e caldo. Alcuni di voi saranno d'accordo con il mio pensiero, altri meno. In un modo o nell'altro si arriva sempre alla classica "guerra di religione" che porta spesso come argomentazioni dialettiche, le personali preferenze per una o l'altra tecnologia. Ma quello che conta veramente è il risultato: come lo si raggiunge ha poca importanza. Ne ha molta invece la qualità e la manutenibilità del sistema.
Per il resto...a voi l'ardua sentenza...
M.
E' da sottolineare che il grande merito di quest'ultima, all'inizio del nuovo millennio, è stato avvicinare una massa di sviluppatori desktop (la maggior parte dei quali legati al buon vecchio Visual Basic 6.0), al mondo web. Il paradigma di programmazione che veniva proposto - nella sua semplicità concettuale - era geniale: simulare il modello "ad eventi" (tipico dei desktop, appunto) applicato al web.
La magia realizzata da "postback" e "viewstate" ha quindi permesso, solo con l'introduzione di qualche nuovo concetto, di aumentare esponenzialmente il numero di web-developers Microsoft, quindi iniettare nuova linfa produttiva nelle vene di Internet, che proprio in quegli anni ha conosciuto il suo grande boom.
Nell'immaginario collettivo, WebForms, è sempre stato sinonimo di grande produttività, con tempi di sviluppo ridotti, e buona qualità del prodotto finale; anche per sviluppatori con una conoscenza non approfondita delle problematiche legate al web.
Per quasi un decennio, WebForms, ha rappresentato l'unico modo di fare "web" su .NET. Ma non tanto una "scelta obbligata": semplicemente perchè non si è mai effettivamente sentita la necessità di cercare altre vie, poichè le esigenze degli utenti non sono cambiate così radicalmente da giustificare una vera rivoluzione. Con i vari framework e service packs, sono state rilasciate implementazioni che hanno sempre più semplificato la vita dello sviluppatore migliorando la qualità del prodotto finale; ma le basi su cui costruire tutta l'intelaiatura è rimasta sostanzialmente la stessa.
Ma negli ultimi 4-5 anni, con la diffusione di Internet in mobilità, e l'introduzione sul mercato di numerosi device caratterizzati da specifiche eterogenee, hanno iniziato a sentirsi sempre più forti i temi del "controllo" sull'output generato, quello della "ottimizzazione" dei dati sul canale e, non ultimo, quello della sicurezza sui dati.
Benchè "WebForms", nelle sue ultime versioni, rispondesse efficacemente a queste nuove problematiche - e vi risponde tutt'ora - è evidente che la produttività, che rappresentava il punto di forza di questo framework, tende a venire un po' se si da molta importanza a queste problematiche. Le "best practices" da mettere in atto per ottimizzare il dialogo client-server e migliorare l'output di uscita, sono molteplici; e molte di esse richiedono delle conoscenze approfondite sia del protocollo HTTP, che di WebForms stesso.
Altra importantissimo aspetto che non va sottovalutato è come la rete sia diventata sempre più "orientata ai servizi" e meno alle applicazioni "chiavi in mano". Molti device fruiscono Internet utilizzando applicazioni native, che sfruttano la rete con il solo scopo di attingere dati nudi e crudi (in formato JSON o XML), demandando la parte di interazione utente e "presentation" a dei moduli locali (le "App").
Da questo punto di vista, a mio parere, ASP.NET MVC ha qualche cosa in più. Diversamente da WebForms, che tende a simulare un ambiente state-full usando viewstate e postback, l'incarnazione Microsoft di Model-View-Controller abbraccia completamente la natura state-less del protocollo HTTP, e sfrutta le specifiche sulle quali è stato concepito fino all'ultima risorsa.
Si ha un controllo completo sull'output emesso per la renderizzazione client (diversamente da WebForms, che viene "infarcito" di strutture atte a preservare lo stato della pagina). E' possibile gestire granularmente l'accesso alla singola risorsa ("Action") verificando i parametri in ingresso nella "request", e fornendo un'adeguata "response". Non ultimo, la natura modulare con cui è stato concepito ASP.NET MVC, va nell'ottica di realizzare applicazioni altamente testabili e maggiormente manutenibili. Ogni singola porzione applicativa (detta anche "unità") può beneficiare della filosofia con cui il sistema è stato concepito il sistema, il "SoC" (Separation of Concerns), e una struttura organizzativa di progetto che rende semplice intervenire chirurgicamente sul sistema anche in fase di maintenance.
Va comunque detto che MVC, usato in maniera del tutto "nativa", è piuttosto ostico da apprendere ed applicare; ma usandolo in combinazione con dei framework client side (cito solo "KnockoutJs", "DurandalJs" o "AngularJs") rappresenta una vera macchina da guerra. Applicazioni prima immaginabili solo in ambiente desktop, sono realtà pubblicate sulla rete; ed MVC è il perfetto backend per incorporare tutta la potenza "server-side" di questi applicativi.
Chiaramente il tema "WebForms vs MVC" è tutt'ora aperto e caldo. Alcuni di voi saranno d'accordo con il mio pensiero, altri meno. In un modo o nell'altro si arriva sempre alla classica "guerra di religione" che porta spesso come argomentazioni dialettiche, le personali preferenze per una o l'altra tecnologia. Ma quello che conta veramente è il risultato: come lo si raggiunge ha poca importanza. Ne ha molta invece la qualità e la manutenibilità del sistema.
Per il resto...a voi l'ardua sentenza...
M.
Commenti
Posta un commento