Vi capita mai di guardare il design del progetto .Net 3.5 su cui state lavorando, orgogliosi di tutti i layer, fino a giungere alla vostra DAL, osservare Entity Framework v1, scelto per diperazione come ORM, pensare alla valanga di pezze che avete messo per usarlo con un entity model agnostico in un contesto detached e... sospirare tristemente chiedendovi "perché gesugesugesù non sono rimasto su NHibernate"?
Ecco. Ne ho fatto una questione personale e, grazie a EFPocoAdapter (sample MS di partenza del supporto al model POCO di EF v2) e a una selva di utility scritte ad hoc per gestire l'attach delle entità ed il loro stato durante insert e update, ne sono uscito vincitore.
Tranne un "piccolo" neo. Che mi manda in bestia.
Perché, mi chiedo, su un modello con una semplice gerarchia di classi TPT (table per type) la più stupida query E-SQL o LINQ to Entities mi genera 3615 (diconsi 3615) righe di SQL per un totale di 270 KB??
E questo è niente, vogliamo parlare dei tempi di compilazione di una query LINQ to Entities (circa 15 secondi per query, non parallelizzata, su un Core 2 Duo a 2,53 Ghz)?
Per carità, precompilando tutto e sfruttando un po' di thread per parallelizzare, salvo tempi di avvio biblici il resto si risolve.
Naturalmente andando verso TPH (table per hierarchy) le prestazioni migliorano (come Daniel Simmons del team ADO .Net velatamente suggerisce, si veda questo thread), ma personalmente piuttosto che devastare la normalizzazione del DB, tolgo l'ereditarietà e via di associazioni, con buona pace del modello (su questo molti puristi del design non saranno d'accordo, ma sui dati sono molto pragmatico).
Dopo questo piccolo sfogo / introduzione, veniamo finalmente a Visual Studio 2010 beta 2 e all'Entity Framework v2.
Come primo test, per tagliare la testa al toro, ho brutalmente aperto la soluzione di cui sopra in VS2010, spostato il target di tutti i progetti a .Net 4 e via di debug.
Risultato: le semplici query citate sono passate da 3615 righe a 1312 per un totale di 93KB. Beh, non male come prima prova, ma temo non abbastanza.
In compenso i tempi di precompilazione sono rimasti biblici, ma questo è solo una conseguenza.
Si tenga presente che siamo ancora di fronte a una beta, per cui tutto può succedere!
Morale:
The good
Ci sono dei miglioramenti tangibili sul fronte ereditarietà, si potrebbe quasi sperare.
The bad
Mi sembra ancora improbabile l'utilizzo di modelli TPT "in produzione", anche se devo dire che grazie al query optimizer di SQL, grossi problemi di performance non ne vedo.
The ugly
Chi vuole può spostarsi su una soluzione TPH, devastando la propria base dati, nel nome dell'entity model.
...oppure urge un workaround di quelli cosmici per salvare capra e cavoli. Stay tuned 
Commenti? Suggerimenti? Qualcuno ha trovato il Graal?
Alessandro Pilotti
[MVP / IIS ]