Discussioni su ADO.NET Entity Framework
Un argomento caldo in questi giorni è il futuro di ADO.NET Entity Framework. Durante TechEd Developers a Orlando si è parlato molto di ADO.NET Entity Framework, molto meno di LINQ to SQL (che ora non è più in carico al team di C# ma a quello di ADO.NET, che è lo stesso che sviluppa Entity Framework - ma questo sarebbe oggetto di un altro discorso che farò quando capirò anche io i piani che hanno realmente). Per molti aspetti, Entity Framework è un ORM molto giovane, ma è fatto da Microsoft, e questo di per sé ne garantirà un uso diffuso.
A causa delle limitazioni esistenti in questa prima versione, è nata una "mozione di sfiducia" (non so come tradurla diversamente) firmata da poco meno di 300 persone (a oggi). Ad ogni modo, non sono numeri così piccoli. Tim Mallalieu ha risposto a queste critiche e il team di Entity Framework ha inaugurato un blog dedicato alla progettazione e sviluppo della versione 2.0 di Entity Framework.
Personalmente, pur non essendo un forte sostenitore di questa tecnologia, credo di comprendere quale sia il problema di fondo. Alcuni (ma forse molti) considerano ADO.NET Entity Framework come un tool di ORM da comparare con tool simili, come NHibernate. Per Microsoft, non è solo questo. Uno dei punti chiave nella visione di Microsoft è che Entity Framework sia un layer di astrazione sul modello dei dati utilizzabile non solo da programmi scritti in C#/VB/ecc., ma anche da tool di reportistica che rappresentano il modello di entità direttamente all'utente finale che vuole realizzare i suoi report. Io non sono così convinto che sia possibile avere un approccio simile nel 100% dei casi, ma devo ammettere che in molte situazioni questa possibilità è adeguata alle esigenze. Nutro forti dubbi sul fatto che possano amalgamare anche i modelli multidimensionali all'interno di Entity Framework (è una cosa che hanno annunciato di voler fare, anche se a oggi non c'è alcuna traccia di feature che vadano in questa direzione) e il rischio latente è che questa visione "universale" porti a fare scelte nell'adozione di questa tecnologia basate sull'attesa di funzionalità future, che chissà se e quando arriveranno.
Ciò detto, ripeto, il fatto di poter supportare un ambiente di reportistica direttamente da Entity Framework giustifica, in effetti, la necessità di avere un proprio linguaggio di interrogazione (Entity SQL) che non sarebbe necessario usando LINQ to Entities. Il vero problema è decidere se e quando usare questa tecnologia. Oggi come oggi, io sarei cauto e inizierei qualche sperimentazione (soprattutto in scenari dove si può sfruttare la capacità di essere un layer di astrazione superiore e non solo un ORM), senza però fare già scelte definitive. In fondo, è (ancora per poco) un prodotto in Beta.
PS: Forse sta passando di moda il politically correct. Un post che riprende il tema della mozione di sfiducia è questo di Dinesh Kulkarni, a suo tempo (ma ora non più) coinvolto nello sviluppo di LINQ to SQL. Dissacrante e divertente, basta essere disposti a fare un po' di auto-ironia.