ASP.NET MVC non è di quelle cose software che passano inosservate come un metodo virtual in una classe. Doveva ancora uscire la prima CTP e già se ne parlava. Era appena uscita la seconda CTP e già ic’era gente che scriveva post su tip (sic!!!) di programmazione. Alla terza CTP molti asserivano di usare MVC in progetti reali.

La prima versione RTM è stata rilasciata in coincidenza con BASTA Italia 2009 (marzo 2009) e la seconda RTM vedrà la luce—quando si dice il fato—in coincidenza con BASTA Italia 2010. A questo punto il pattern è chiaro… O no?

Microsoft presenta ASP.NET MVC come una alternativa al classico modello Web Forms . E in effetti non ha tutti i torti perché oggi, a conti fatti, è molto difficile scegliere tra uno e l’altro. La scelta è difficile perché non vi sono differenze sostanziali con Web Forms a parte chiaramente il modello di programmazione. La scelta è difficile perché è quasi esclusivamente una scelta da programmatori. Io, in quanto programmatore, posso essere attratto da ASP.NET MVC che offre un ambiente estendibile, flessibile, ben scritto e che mi porta (probabilmente, ma non sicuramente) a scrivere codice migliore.  Con ASP.NET MVC il codice è inerentemente più facile da testare e disegnato con un minimo di separazione tra i vari strati. Tutto ciò è impossibile in Web Forms? Anche in Web Forms si riesce ad arrivare ad un buon livello di SoC e testabilità. Ci vuole disciplina e impegno, ma ci si arriva. 

Ma la  domanda è: tutto questo che impatto ha sulle scelte tecnologiche di un progetto? Esiste un qualche ambito funzionale dove vi sono chiari benefici ad usare ASP.NET MVC? Esiste qualcosa che ASP.NET MVC fa che non è possibile con Web Forms? Di cose ne esistono, ma sono tutte per la stragrande maggioranza legate all’universo del programmatore (fissazioni comprese) e hanno impatto  zero sul business.

La maggiore testabilità del codice finale non è un argomento facilmente spendibile per giustificare la scelta di ASP.NET MVC in un progetto.  Soprattutto se la scelta di ASP.NET MVC finisce per avere un contraccolpo in termini di formazione. Per giustificare la scelta di ASP.NET MVC ci vogliono altri, e più solidi, argomenti. Ce ne sono?

Almeno uno c’è: il controllo totale sull’HTML. Non è una cosa da poco perché significa accessibilità, supporto cross-browser, XHTML, stili.

A fronte di requisiti non-funzionali di questo tipo, ASP.NET MVC diventa una scelta estremamente valida perché consente di ottenere il rispetto del requisito a costi relativamente bassi. Ecco perché ASP.NET MVC è un framework che ciascun responsabile di team che opera nel mondo Web deve considerare e conoscere e valutare seriamente nell’ottica della crescita professionale del suo team.  Che poi ASP.NET MVC sia trendy e cool, alternativo e altnettico, chi se ne frega…

Con il rilascio di Visual Studio 2010 ci si ritrova con due tipi di progetti Web. Perché due modelli diversi ma funzionalmente analoghi? Nessuno lo confermerà mai, ma credo ci siano sotto soprattutto ragioni di marketing. Detto questo, però, è impossibile tacere la veneranda età di Web Forms e la necessità di una sua revisione. ASP.NET MVC è forse un po’ troppo alternativo per essere il futuro di Web Forms. E non è nemmeno perfetto. Ma Web Forms deve evolvere, cambiare pattern e architettura.

Oggi, 2010, per un progetto Web la scelta è ASP.NET Web Forms o ASP.NET MVC. Domani potrebbe non esservi più scelta, ma l’unica opzione potrebbe essere qualcosa di diverso. La solita storia dei due litiganti e del terzo incomodo.