.NET Architectonics

Con ASP.NET MVC 2 appena rilasciato si parla già (e oserei dire da un pezzo) di MVC 3. Oramai ho perso ogni speranza di vivere in un mondo che vada ad una velocità di sviluppo "sostenibile" e dunque a questa sequenza continua di release--una sorta di Continuous Integration--mi sono oramai arreso.

Tuttavia, guardando nello specifico di ASP.NET, credo che MVC 3 sia una milestone chiave -- a prescindere dalle feature che conterrà. Premesso che non ho partecipato ad alcun meeting segreto in quel di Redmond, quello che dico lo dico sulla base del ragionamento e dell'analisi "statica" della piattaforma ASP.NET.

Web Forms è vecchio di dieci anni e comincia a mostrarli tutti.

È ancora efficiente e durerà a lungo, ma forse è il caso di chiedersi se cambiando approccio non si possano ottenere risultati migliori almeno per alcuni progetti. Anche se nessuno lo dice, Microsoft sa che deve unificare (e presto e bene) ciò che ha diviso: Web Forms e MVC. Inoltre, deve farlo in un modo che incorpori in modo naturale AJAX ed esponga un modello operativo che sappia essere anche asincrono senza richiedere cambiamenti radicali.

Già in ASP.NET 4 non ci sono novità architetturali sostanziali. Nel futuro breve (sento parlare di un .NET 4.5 intorno ad un service pack di VS 2010), ci potrebbe essere un modello MVP dentro Web Forms--ma sono bruscolini. Architetturalmente parlando MVC è di un altro pianeta.

Lo sto utilizzando per uno sviluppo intensivo nel senso di "compresso-nel-tempo". Nulla di drammatico: una  decina di progetti, un centinaio di classi, un modello dati di una ventina di entity, una decina di servizi nel service layer. Nessun calo evidente di produttività. Semmai necessità di tenere alta l'attenzione sempre e quindi meno stupidaggini fatte per la fretta. Direi quasi che ti costringe a fare considerazioni YAGNI (si/no) ad ogni passo. Dopo un po' il tutto viene automatico. Design del codice naturalmente più pulito. ATTENZIONE: non è che MVC faccia magie, ma non ti ostacola nella creazione di codice layered.

E soprattutto un'applicazione 100% AJAX si sviluppa in modo pulito e chiaro, con pochissimo JS ma la possibilità di metterci tutto il jquery che volete.

Il futuro di ASP.NET passa da MVC. Se volete parlarne il 24 e 25 maggio ci sono gli X-Course di Overnet a Milano a prezzi davvero competitivi.

Se poi volete approfondire, la settimana del 14 giugno a Milano c'è Software Design & ASP.NET 4 e MVC.

Se non fosse un'espressione piuttosto seria e indirizzata a contesti ben più specifici, l'espressione sviluppo sostenibile sarebbe perfettamente adeguata alla situazione. Da un lato, come oramai si ripete da tempo, è necessario tornare a porre molta più attenzione che nel recente passato ai principi di design del software; dall'altro è fondamentale poterlo fare senza sovraccaricare il team.

Non si tratta di concetti o forse, meglio, di un'equazione del tutto nuova. Molti team all'avanguardia adottano forme di sviluppo sostenibile da almeno un quinquennio. Il punto è: farlo tutti. Ovvero, programmare meglio, tutti.

I test non sono una figata da geek dell'ultima ora; sono una necessità per verificare costantemente quanto bene il team stia facendo. I principi SOLID non sono la noiosa teoria che ci piacerebbe tanto poter prendere alla lettera se solo avessimo tempo. Sono il fondamento di ogni pezzo di codice che sia mantenibile e gestibile. Il refactoring non è una perdita di tempo, ma un esercizio costante che se trascurato modifica la "postura" del codice. E chi lo ha provato sa bene quanto lungo e doloroso possa essere un ciclo correttivo di ginnastica posturale :)

Tutti d'accordo sulla teoria allora? E la pratica? All'atto pratico a fare test, refactoring, ad applicare pattern e idiomi si "perde" tempo. Se funziona--dice il capo--perché rischiare di rompere tutto per rendere il codice più "bello"? Onestamente, credo che un corso sui principi SOLID e sul loro ROI matematico servirebbe di gran lunga più a un project manager che ad una schiera di sviluppatori junior o poco più. Che sono quelli che spesso si trovano nei pochi corsi e incontri pubblici sul tema.

Per coniugare principi e tecniche corrette con i tempi sempre troppo ristretti di un progetto servono strumenti ad hoc. Nell'ambito .NET lo strumento principe è Visual Studio. E di Visual Studio 2010 assisteremo la prossima settimana al lancio ufficiale. In particolare, lunedi 12 aprile a Roma nella festosa cornice di BASTA Italia, ci sarà un workshop su VS 2010 tenuto da me e da alcuni esperti Microsoft. La prima parte del workshop sarà dedicata proprio all'analisi delle nuove caratteristiche di VS 2010 per lo sviluppo sostenibile. Si tratta sostanzialmente di strumenti di editing, IntelliSense, code-completion e refactoring che se presi singolarmente non dicono molto usati sistematicamente nel corso di progetti anche di piccolo cabotaggio fanno una differenza abissale. Provare per credere. In fondo, usare VS 2010 è molto molto vicino ad avere VS 2008 Team System con ReSharper dentro e Reflector integrato. Tutto in uno strumento solo.

Infine, per quanto mi riguarda nel workshop di lunedi offrirò una panoramica su ASP.NET 4 e MVC 2 e una passata su alcuni aspetti di Entity Framework e Workflow.  Per maggiori dettagli e approfondimenti vi rimando poi alle sessioni del 13 e 14 aprile e ai workshop finali di Giovedi 15 e Venerdi 16.

Alla prossima settimana!

A volerlo fare apposta non ci saremmo riusciti ... e infatti non ci abbiamo nemmeno provato. Ma--grande segno della benevolenza degli dei--ci siamo riusciti

BASTA Italia va in onda in concomitanza intergalattica con il lancio di VS 2010 a partire dal 12 aprile in quel della capitale.

Precisamente: Roma, Holiday Inn, Parco dei Medici (Muratella)

Comoda location, a poche fermate di treno da Fiumicino, Roma Ostiense o Tiburtina. E un paio di Km dal raccordo.

E che contenuti: ASP.NET MVC, software design, SharePoint 2010 e WPF/Silverlight. La conferenza  è su 2 giornate centrate soprattutto su Web development e SharePoint, ai quali vanno aggiunti 3 giorni (Lunedi, Giovedi, Venerdi) di workshop che sono un'ottima occasione per rinforzare le difese dell'organismo contro la complessità del software moderno.

Alcuni dei contenuti--fatemelo dire--sono adatti anche a figure professionali di alto livello (architetti e dirigenti). La complessità del software di oggi--è questo uno dei messaggi chiave della conferenza--si combatte e affronta con strumenti e approcci diversi dal passato in cui ha dominato il paradigma RAD. Le novità di VS 2010 Ultimate stanno a dimostrarlo e i workshop su design del software 2010 vi offrono la possibilità di vedere oltre l'ostacolo e magari fare scelte che paghino già a breve termine.

Bisogna darsi una mossa e capire che il mondo del software in 5 anni è cambiato di brutto e chi non si adatta scompare. Senza che Darwin ci possa fare nulla ...

Arrivederci a Roma, BASTA Italia , 12-16 aprile.

E' il tormentone del momento (anzi, gia da un bel po' ...)

Tutti lo vogliono (e a ragione), ma quando serve davvero? O meglio qual è un vantaggio chiaro e tangibile che offre al cliente prima che allo sviluppatore? I miei due centesimi sono su DotNetCenter.

E per chi ci sarà ne parliamo anche a BASTA Italia, Roma 12-16 Aprile in coincidenza con il lancio mondiale di VS 2010. Quando si dice il caso... e si che di caso si tratta visto che la data era stata fissata prima dell'annuncio natalizio di ScottGu sul ritardo di VS2010.

Ah come passa il tempo ... anche per me :)

Al termine di alcune piacevoli giornate di training OOD a pranzo butto lì un riferimento a DotNetCenter.IT. Portale DeV che se pure da poco online era noto ad alcuni dei ragazzi. Ma quando ho chiesto se ricordavano la "mitica" rubrica Variazioni sul Tema", beh, gli anni di differenza si sono visti tutti...

La gioventù programmatizia di oggi non ricorda. E francamente non può ricordare visto che sono nati (fortunelli) con .NET. Ma c'era un'epoca e nemmeno tanti anni fa in cui non era così... Ma basta con le menate dei  bei tempi andati.

Correte a leggere del nuovo virus (non software) che minaccia gli sviluppatori .NET. Altro che h1n1. Il vero pericolo e' il nuovissimo H1-CTP1.

E, haz, è solo un'anteprima...

PS: per collaborare con DotNetCenter.IT, email ore pasti via blog.

E' da tanto che mi ripromettevo di farlo. Ma da solo non ce l'ho mai fatta. Fondamentalmente per pigrizia...

Ma adesso ci siamo. DotNetCenter.it.

Occupazione? Portale per chiunque si occupi di piattaforma .NET. Articoli, interviste, notizie, recensioni, etc. Collaborazioni aperte, anzi spalancate. Nello stile VTema di 15 anni fa, email ore pasti:  dino at dotnetcenter.it

Soprattutto con DotNetCenter torna e stavolta davvero Variazioni sul Tema.

E' straordinariamente frequente che ancora oggi qualcuno si ricordi di quella "mitica" (ma si diciamolo) rubrica sull'altrettanto mitica Computer Programming. E badate i primi articoli sono del 1995. (Millenovecentonovantacinque).

C'era ancora Windows 3.1 for Workgroup. E sarebbero passati altri 5 anni prima della alpha di .NET.

Variazioni sul Tema era (e torna ad essere) una rubrica semiseria con cui farsi due risate (perlopiu' amare) e riflettere su come va il mondo .NET. Ci saranno puntate dichiaratamente ironiche e altre un po' più riflessive. Ma spero ci sia (come in passato) materia grigia all'opera.

Si comincia con un classico. Una delle puntate più riuscite è del 1995 scritta per celebrare il rilascio di Windows 95. Oggi 14 anni dopo in occasione del rilascio di Windows 7, Variazioni sul tema ritorna per celebrare... Windows Settimio. 

Feedback?

Ho trovato questo post di oramai 5 anni fa che discute la penetrazione di ASP.NET sul mercato delle WebApp. E mi chiedevo se qualcuno conosce riferimenti più recenti.

Grazie!

A parte un discreto insieme di novità per AJAX, non è che ASP.NET 4.0 offra poi granché. Chi si illudeva di trovarci magari una schema di implementazione per MVP è per ora rimasto deluso. La parola d'ordine sembra essere "più controllo". E in effetti se escludiamo rivoluzioni filosofiche non è che sia rimasto molto da sistemare. Quindi o ci sta bene com'è o ci si rivolge a ASP.NET MVC.

Una cosa effettivamente sistemata per il meglio (oddio, a parte la confusione tra proprietà un pochino sovrapposte) riguarda il viewstate.

Non starò qui a menarla (ancora) sul fatto che il viewstate non è un modo perverso di appesantire le pagine. Che ci crediate o no, il viewstate serve a qualcosa e lasciarlo nella pagina è la soluzione con meno controindicazioni.  Detto che il viewstate di fatto serve realmente solo per pochissimi controlli in una pagina, fino ad ASP.NET 3.5 SP1 si scopre che in effetti opt-out è il solo approccio supportato. Tradotto, che vuol dire?

Il viewstate è controllato dalla proprietà booleana EnableViewState. E uno pensa che gli basta disabilitarlo sul controllo che vuole e tutto va a meraviglia. Sbagliato. Se il viewstate è abilitato sulla pagina (in generale sul container di un controllo) ogni controllo  figlio ne eredita il valore. Punto. E soprattutto indipendentemente dal valore di EnableViewState sul controllo stesso.

Ora in ASP.NET 4.0 potevano semplicemente invertire la logica nel setter di EnableViewState. Ma questo probabilmente avrebbe causato casini con le miriadi di applicazioni esistenti. Ergo, appare dal nulla una nuova proprietà: ViewStateMode. La proprietà può assumere tre valori (Disabled-Enabled-Inherit) ovviamente riferiti allo stato del viewstate sul controllo. Grazie a questa proprietà, il supporto per il viewstate in ogni controllo diventa opt-in ovvero ciascun controllo decide se vuole il viewstate o no. Soprattutto può farlo indipendentemente da ci; che fa il parent.

Tutto facile? Manco per sogno

Per un vero scenario opt-in seguire le istruzioni:

• EnableViewState per la pagina/container deve essere sempre true
• ViewStateMode per la pagina/container va messo a Disabled
• ViewStateMode per i controlli che si vuole va messo a Enabled

Al momento altre combinazioni o non funzionano o non danno risultati predicibii.

Mentre noto che da qualche anno si parla molto di testing, mi pare di rilevare una minore attenzione verso uno degli attributi fondamentali del software, almeno stando agli standard internazionali ISO/IEC--la testabilità del software.

Cosa conta di più, allora?

Beh, il testing è sotanzialmente il risultato dell'esecuzione di una serie di programmi ad hoc (OK, intendo automated testing) volti ad assicurare che le classi (unit) o il sistema nel suo insieme si comportano come ci si aspetta in relazione al codice ed eventualmente a componenti esterni.

Il testing ci dice che il software funziona. O più esattamente ci dice che le funzioni/scenario che abbiamo testato funzionano. Il che non è male, ma non è nemmeno certezza assoluta. Come scriviamo con Andrea in "Architecting Applications for the Enterprise", il testing e in particolare lo unit-testing serve solo al team per darsi la sicurezza che si sta procedendo sulla giusta strada e per crearsi uno strumento di difesa contro regressioni post-modifiche.

La testabilità, invece, ci porta a scrivere codice che sia semplice da sottoporre a unit-testing. E come è possibile ciò? Sostanzialmente facendo uso di principi di design e opportuni pattern. Alla fine, il paradosso sapete qual è? E' che la testabilità serve non direttamente al testing, ma ad avere soprattutto codice migliore e meglio disegnato. Il testing è una scusa per dedicarsi seriamente alla testabilità.

E la testabilità del codice comincia dalla definizione di software contracts. O come li chiama MS (che deve sempre distinguersi...) code-contracts. Oggi anche per VS 2008 in attesa di .NET 4.0 e VS2010.

Certo talvolta la testabilità rischia di fare a pugni con la purezza del design OOD. Ma la ricerca della testabilità porta a codice più flessibile, modificabile e anche leggibile. E se poi non è puro OOD... chi se ne frega. E se, come dice un esperto del campo--il mio amico Roy Osherove--fosse ora di cambiare alcune definizioni di OOD?