L’avvio di un nuovo progetto web, di una nuova applicazione, reca con se sempre una domanda nei confronti della quale le risposte non sono sempre esaustive. Accade anche che si possa essere influenzati da trend che apparentemente tendono ad assumere un valore ben superiore a quello che un’attenta analisi potrebbe attribuire loro. Prendendo spunto da un mio precedente articolo (ormai parecchio datato) relativo alla scelta tra ASP Classico e ASP.NET vorrei ora tentare la medesima analisi di discrimine tra due delle tecnologie maggiormente in voga tra gli sviluppatori che hanno focalizzato la propria attenzione sul framework .NET.
Uno dei fattori chiave nel successo di ASP.NET è da ricercarsi nello sforzo fatto dagli sviluppatori del framework .NET volto a rendere il più simile possibile lo sviluppo di applicazioni per il web allo sviluppo di applicazioni per il desktop. La chiave di volta è certamente la persistenza di stato : mentre le applicazioni desktop (Winforms) vivono e girano nella piena cognizione di stato, le applicazioni per il web basate su ASP Classico sono intrinsecamente prive di cognizione di stato (stateless). Questo handicap è stato superato mediante l’adozione dell’oggetto viewstate che, reinviato tramite postback dal browser al server, permette all’applicazione di ricostruire lo stato dell’intera sessione applicativa e, in aggiunta, di poter facilmente implementare il sistema degli eventi a cui i controlli web rispondono, esattamente come se si trattasse di controlli di un’applicazione desktop.
Ovviamente non si riduce tutto a questo. ASP.NET, considerato come evoluzione di ASP Classico, ha l’indubbio vantaggio di aver tradotto in modelli e componenti tutte quelle che erano, e sono, le best-practice per un corretto sviluppo Web: post-back, popolazione automatica dei campi di input, autenticazione ed autorizzazioni prima del rendering delle pagine , compilazione del codice ecc, non sono caratteristiche cavate dal cilindro. Anche in ASP Classico l’adozione di oggetti COM per la separazione della presentazione della logica dell’applicazione o per i componenti server come le griglie di dati fino ad arrivare alla persistenza di stato erano tecniche considerate all’avanguardia e spesso indispensabili.
Ma se per costruire una pagina ASP Classica dovevate avere nozioni di html, di linguaggi di scripting, di integrazione di oggetti COM (nonchè del loro sviluppo) ecc., con ASP.NET tutto quello che dovete sapere riguarda quasi esclusivamente la sintassi .NET del linguaggio che preferite. Cosa che ha reso la curva di apprendimento di ASP.NET più facile per i programmatori di applicazioni Desktop rispetto a quanto non lo sia stato per programmatori di applicazioni Web basate su ASP Classico.
Il mondo in generale non è perfetto: nemmeno ASP.NET lo è. Innanzitutto non fornisce intrinsecamente un paradigma di separazione dei livelli applicativi permettendo allo sviluppatore di mischiare, all’interno della stessa pagina logica, convalida e accesso ai dati. E’ pur vero che con il code-behind si acquisisce un certo grado di separazione tra logica e presentazione ma, nei fatti, una pagina .aspx va considerata indissolubilmente unita alla sua porzione di codice.
La persistenza di stato viene perseguita attraverso l’adozione di un campo hidden denominato viewstate: il numero sempre crescente di controlli server disponibili e l’aumentata quantità di dati necessari alla corretta gestione di un numero sempre crescente di eventi a cui possono rispondere, rende, a volte, il contenuto di questo campo davvero pesante con evidenti impatti sulla velocità delle applicazioni: i client infatti reinviano al server non solo i dati immessi dall’utente ma anche l’intero viewstate. Considerando che le normali connessioni in banda larga (ADSL) sono sbilanciate a favore del download e sono molto limitate in upload questo può rivelarsi essere un problema. E’ bene comunque notare che nonostante questo aspetto sia considerato il mostro di ASP.NET , a mio avviso, è un aspetto francamente sopravvalutato: viewstate infatti può essere controllato e memorizzato lato server per poi essere richiamato al momento opportuno e con l’avvento di .NET 4.0 se ne può facilmente controllare la dimensione.
Ben più importante ai nostri giorni è invece l’astrazione dal codice HTML che implica la compatibilità con browser di vario tipo e l’integrazione con framework di scripting come jQuery, Dojo e PrototypeJS. Inoltre il modello post-back, che forza le pagine a reinviare i dati a se stesse, non è molto gradito dai motori di ricerca che invece prediligono link in chiaro, con parametri possibilmente tradotti in stringhe leggibili anche dagli utenti. Anche in questo caso, comunque, esistono le tecniche per aggirare il problema: URL rewriting e integrazione AJAX hanno reso anche le pagine ASP.NET più gradite ai motori di ricerca.
Ma allora ? Perchè MVC ?
L’acronimo MVC sta per Model-View-Controller ovvero uno schema progettuale per un’interfaccia utente che separa la rappresentazione dell’informazione dal modo con cui l’utente interagisce con questa informazione. Il Model è la rappresentazione astratta dei dati e della logica che li mantiene, il Controller è l’oggetto che fa da tramite tra l’utente e i dati mediando l’input o l’ouput, mentre la View è l’oggetto demandato alla rappresentazione dei dati. ASP.NET MVC è un framework totalmente nuovo espressamente progettato verso specifici obiettivi : rigida e netta separazione dei dati dalla presentazione e dalla logica della loro manipolazione; ripresa del totale controllo dell’output html da parte del programmatore; testabilità (ma su questo aspetto soprassediamo per il momento).
La prima cosa da sottolineare è che MVC non è un sinonimo per identificare la separazione in livelli (tipicamente 3) di una applicazione client server. MVC è un framework di interfaccia utente e basta. Nella segmentazione in Data-Access-Layer <-> Business Logic Layer <-> User Interface, MVC riguarda solo il 3 livello.
E non è nemmeno un sostituto o qualcosa di intrinsecamente “migliore” di Webforms: è solo un’alternativa.
Quando si progetta un’applicazione ASP.NET MVC si ragiona in termini di controllers e views. Si prendono decisioni sul come passare i dati alle view e su come far gestire il BLL ai controllers. Il controller sceglie quale tipo di view visualizzare in funzione dell’URL richiesto e sugli eventuali parametri passati. Ogni richiesta viene eseguita mediante l’esecizione di un metodo su una classe controller. Non sono richiesti postback per eseguire una richiesta, non c’è viewstate per fissare lo stato di una pagina, niente controlli nascosti ed autogenerati nell’ HTML inviato al browser.
In pratica è come ritornare al vecchio html dove il programmatore ha il controllo di ogni singolo pezzo di codice prodotto, e nessuna cognizione di stato.
Come in tutte le cose anche MVC non incarna la perfezione. Numerosi sono i fattori da considerare nella sua adozione. Vediamone alcuni:
In generale direi che la conclusione non può essere assoluta in favore di un modello o dell’altro: considerando che MVC non è qualcosa in contrasto con Webforms vale sempre, secondo me, l’assunto secondo il quale è da preferirsi, in funzione delle necessità del progetto, l’adozione del modello su cui il team di sviluppo si sente più produttivo evitando di abbandonarsi acriticamente, solo perchè si è letto su decine di post che è meglio questo o quello, ad una soluzione che non si padroneggia completamente.