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.
paparesta wrote:
diciamo che ci convivo e che
forse per le mie necessità L2Sql sia sufficiente.
ah, ovviamente è solo per SQL Server, ma questo nel nostro caso non è stato un problema, anzi
>per scoprire che uno spazio tra nome
>della classe e namespace, dopo la virgola, può cambiarti la vita,
Io mi accontento di poco, se avesse dato un messaggio di errore decente da farti capire il problema sarei stato contento, invece di restituire errore generico nel file di configurazione.
:D:D:D
Ciauz
Post che mi interessa da vicino, sto cercando di scegliere che tipo di architettura usare in alcuni miei software, che devo dire assolutamente meno sotto carico del vostro e dopo aver letto il libro di Pialorsi e Russo su Linq mi stavo orientando proprio verso LinqToSql. Leggendo in giro e facendo alcune domande però molti considerano LinqToSql non proprio adatto per fare software di tipo "enterprise", per cui ti posso chiedere se avete preso in considerazione per il dal altri framework OR\M tipo Nhibernate e cosa vi ha fatto scegliere LinqTOSql ? Mi conforta vedere che altri lo stanno usando in software che non siano solo procedure di amministrazione, penso che il discorso legato alla produttività di questo framework sia un fattore importante da tenere in considerazione.
Stefano
Guarda ti rispondo io ;)
Abbiamo tenuto in considerazione anche altri ORM, e la scelta è nata su LinqToSql per due ragioni, semplicità di utilizzo e db nuovo.
Personalmente sono un fan di NH, ma nel nostro caso non era la scelta migliore.
Quando discutevamo su quale ORM scegliere abbiamo analizzato, esperienza del Team con il possibile ORM, skill del team di sviluppo, possibile supporto della ditta produttrice, cose non da poco.
Con L2S è molto più facile da utilizzare, se sbagli a scrivere non ti compila, con NH e EF, il mapping è un po' più complesso e, nel caso di NH, le query sono stringhe e se uno sbaglia a mettere un punto te ne accorgi a runtime.
Se sei sicuro che questo non provochi problemi/rallentamenti nel tuo team perchè esperto di NH e ha un skill medio/alto, allora va benissimo scegliere NH o EF.
Oltre a questo abbiamo tenuto in considerazione che il disegno del database è stato fatto da zero, idem per L'object Model e questo ci ha permesso di non avere grandissimo problemi con L2S.
Resta il fatto che dove L2S non è arrivato siamo andati a mano.
Per quanto riguarda WCF la questione è dura.
Resto dell'idea che dopo Excel è il più bel prodotto Microsoft, ma anche uno dei meno documentati.
Quando solleva delle eccezioni riuscirne a tirare fuori qualcosa è veramente dura.
Ciauz
come ha detto Ugo, se parti adattandoi a LINQ to SQL, hai enormi vantaggi in produttività. fermo restando che in alcuni passaggi abbiamo dovuto rivedere un attimo modello ad oggetti/db perchè sulla carta era fantastico, ma poi LINQ to SQL non era d'accordo
) personalmente ho imparato molto da questo progetto e credo che l'unico vero difetto che ha LINQ to SQL sia nel come gestisce l'ereditarietà, con quel suo meccanismo che è un po' così. io personalmente non sono un fan di NH, nè degli ORM in generale, ma con LINQ to SQL sono riuscito tutto sommato a farmelo piacere.
non è vero che non è scalabile o manutenibile, specie se usi le lambda anzichè la query syntax (cosa che preferisco, quando possibile). in alcuni casi viene meglio usare l'una ed in altri l'altra, in alcuni casi una cosa facile in un modo è quasi impossibile nell'altro.
e nel progetto di cui stiamo parlando, infine, il modello ad oggetti è tutto sommato semplice e la grande limitazione del mapping 1:1 tra oggetto e tabella nel nostro caso specifico non è stato un peso troppo grande. e, problemi bloccanti a parte, direi che ci abbiamo messo circa 1/3 del tempo necessario a fare la stessa cosa nel modo canonico
Dimenticavo, in caso di cache distribuita L2S è un problema :)
Il domain non è serializzabile, la PI di NH avrebbe aiutato parecchio.
Abbiamo dovuto fare dei "work around" per poter mettere i nostri oggetti nella cache distribuita.
Ciauz
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Stampa 
Download 
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!
Grazie per le risposte, beh penso che allora proverò ad usarlo per un progetto che a breve termine dovrò far partire. Le motivazioni che vi hanno portato ad usarlo sono simili alle mie, per cui credo proprio che ci proverò. Io Nh lo uso ma non al 100%, è un bell'oggetto, ma non riesco tanto a farmelo piacere, diciamo che ci convivo e che forse per le mie necessità L2Sql sia sufficiente.
Ciao
Stefano
Continua »»» | Rispondi »»»