Per reale, più che altro, intendo assurdamente delicato :) Da gennaio a luglio è stata sviluppata la nuova versione della community di MTV, dopo la prima che è stata online per un anno circa.

Si è scelto di ripartire da zero, con una soluzione home made, perchè semplicemente abbiamo scoperto che Community Server non è fatto per quel tipo di carico. Giustamente Ugo ha preferito lavorare con tutte tecnologie nuove e questo ha rappresentato un problema in non pochi casi.

Quando si abbraccia una tecnologia appena rilasciata è facile che si trovino tutti i bug, le idiosincrasie e le stranezze possibili. Ed è facile che si scopra di fare le cavie, tutto sommato. Ammetto di aver provato un po' di astio nei confronti di VS 2008 e TFS 2008, perchè non reggevano bene le soluzioni. Con le patch sul Javascript uscite successivamente, qualcosa è migliorata.

Fermo restando che sono rimasto farevolmente impressionato dalla enorme produttività che LINQ to SQL garantisce se si parte disegnando il database come il modello ad oggetti, ho anche capito che è necessario un po' di rodaggio per sfruttarne appieno la caratteristiche. Posso dire però con assoluta certezza che è una scelta che ha fatto risparmiare non poco tempo in fase di sviluppo, ma ha portato anche ad alcuni compromessi. E spesso lo si utilizza male perchè ci si dimentica che, tutto sommato, LINQ to SQL è magia, ma sotto ha un database.

Si è optati per un'architettura SOA, dunque si è fatto un so massiccio di WCF. Devo dire che perdere tempo a cercare di capire perché non trovi un assembly che c'è, è definito nella configurazione e non si sa per quale motivo non viene recuperato, per scoprire che uno spazio tra nome della classe e namespace, dopo la virgola, può cambiarti la vita, è una di quelle cose che ti fanno riflettere su quanto fragili siano le tecnologie attuali e su quanta (inutile?) frenesia ci sia nel rilascio di alcune.

Tutto sommato sono abbastanza contento di aver usato WCF in questo modo (cioè, non per niente banale), ma se non ci fosse stato ScaleOut a tenere in cache il mondo intero, con tutte le sue belle funzionalità, e Stefano a capire perchè WCF ce l'avesse con noi, non saremmo qui a cantare vittoria. Tenetelo a mente se decidete di andare verso questo genere di soluzioni, investendo in un sistema di cache distribuita come nCache, ScaleOut o, quando ci sarà, Velocity. La cache di ASP.NET è un giocattolino, lento e per niente scalabile. Se volete lavorare con i servizi, il minimo è fare cache di dati in maniera aggressiva, altrimenti poi non c'è da meravigliarsi se l'applicazione ad un tratto fa puff.

I veri problemi sicuramente sono stati nel far lavorare bene WCF e LINQ to SQL, nel mischiare opportunamente gli attributi sulle classi dell'object model per far sì che funzionassero entrambi: sono sempre stata una persona attenta ai particolari, ma con questi due ragazzi ci vogliono sempre 8 occhi!

Da questo progetto abbiamo tratto un bel po' di esperienza, perchè cose come usare l'AOP su WCF mica ti capita di vederle funzionare tutti i giorni :)

Ho condiviso questo progetto con signori come Ugo, Stefano, Alessio e  Marco. E potete solo immaginare quanto ci siamo divertiti nell'acquario! :)

Infine, un monito: cercate di fare in modo che il team capisca appieno dove lo state portando, perchè l'uso di così tante tecnologie nuove può essere un po' pesante da digerire.