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.

Webforms

Vantaggi

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.

Svantaggi

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 ?

MVC – Cosa è

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.

Vantaggi e svantaggi

Come in tutte le cose anche MVC non incarna la perfezione. Numerosi sono i fattori da considerare nella sua adozione. Vediamone alcuni:

• PRO : La pulizia dell’Html generato dipende totalmente dagli skill del programmatore che ne ha il controllo totale. Ne consegue una migliore estensibilità ed integrazione con i più diffusi framework di scripting (anche se questo non è più un problema anche per Webforms da .NET 3.5 in avanti)
• CONTRO : Non sono disponibili controlli server complessi e anche solo per costruirvi una tabella dati dovrete ricorrere al vecchio spaghetti-code;
• PRO : Niente viewstate o script generati (axd) di cui non avete il controllo;
• CONTRO : Niente più programmazione ad eventi poichè dovrete generare manualmente le chiamate con opportuni parametri ai controller per eseguire determinate azioni;
• PRO : Il modello MVC è vincolante e pertanto obbliga lo sviluppatore a separare l’accesso ai dati dalla loro presentazione;
• CONTRO : Ogni vincolo è, appunto, un vincolo. Nella rapida prototipazione di applicazioni questo può essere un fattore di rallentamento allo sviluppo. Utilizzando Webforms è possibile ottenere lo stesso livello di astrazione purchè sia il programmatore a decidere di farlo;
• CONTRO : MVC espone al pubblico l’architettura Web ed in molti casi anche i processi di convalida dei dati;

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.

Da qualche giorno, sui canali commerciali della TV, è comparsa, martellante, la pubblicità di un cosiddetto concorso per vincere premi rispondendo, via sms, ad una domanda talmente semplice che anche un idiota analfabeta potrebbe facilmente azzeccarne la risposta. Il concorso risponde al nome di All You Can.it ( AYCIT ) e richiede di inviare la risposta via sms al numero 48182 per poter essere sorteggiati nella potenziale vincita di un iPhone o un iPad oppure 500 euro di ricarica telefonica.

Prescindo dal fatto che non mi stupisce più che ci sia ancora qualcuno che casca come un pirla in questi tipi di adescamenti, e ancor meno mi stupisco del fatto che ci siano personaggi (più o meno) famosi che prestano la loro faccia allo spot ( l’ultimo che ho visto è Marco Predolin … non certo un genio ma … ) … motivo per cui cerco di spiegare perchè non dovete assolutamente inviare la risposta o in alcun modo partecipare a questi tipi di concorsi, inclusi quelli che vorrebbero regalarvi suonerie o sfondi per il cellulare.

• Innanzitutto il nome … AllYouCan.it in inglese suona come all you can eat  ovvero tutto quello che riesci a mangiare: ed è garantito che quelli che faranno un abbuffata di soldi (i vostri soldi) non siete certo voi ma i gestori di questo cosiddetto servizio;
• E poi questi chi sono ? Avete provato ad andare sul sito ? Al momento in cui sto scrivendo queste righe il loro sito è completamente vuoto ma la cache di google riporta questa immagine:
  
• Come potete vedere vendono servizi in abbonamento alla bellezza di 24 e rotti euro al mese
• Il quiz : la domanda è talmente banale che invece di precipitarsi a rispondere bisognerebbe domandarsi “ma chi diamine non saprebbe rispondere ad una scemenza del genere ?“. Da questo consegue il fatto che il numero dei partecipanti, se fossero tutti cerebrolesi, sarebbe altissimo quindi riducendo le vostre probabilità di essere estratti poi tra quelli che hanno azzeccato la risposta.
• Ma c’è di più. Se anche non avete pensato alle probabilità di vincere ( e vabbè … ) dovete sapere che rispondere al quiz ed inviare il messaggio via SMS non significa partecipare solo all’estrazione dei premi ( sai che roba … 500 Euro di montepremi totale ): significa accettare le condizioni del loro servizio e iniziare a pagare da subito 24 euro (e rotti) al mese. Per che cosa ? Per qualche suoneria ed il miraggio di vincere un iPhone ? Ma per piacere … dai aprite gli occhi !!!

Durante la sincronizzazione della Rubrica Fuori Rete, il client Outlook può ricevere l’errore indicato che sta a significare oggetto non trovato.

Le soluzioni che trovate sul web sono le più disparate :

• verificare che l’indirizzo IP locale del server Exchange sia escluso da connessioni Proxy
• verificare che esista il puntamento DNS all’host autodiscover
• verificare che l’oggetto Default Offline Address Book esista
• …

Tutte cose sacrosante da verificare. Ne manca una però : controllare che il servizio Microsoft Exchange System Attendant sia attivo !!!

Azz ci ho perso l’ennesima ora.