Riflessioni su Entity Framework v1 e vNext #2

EntityClient

• Entity Framework != O/RM

Sappiamo tutti che il buon vecchio pattern in un ADO.NET Data Provider è Connection/Command/Reader, dove attraverso una connessione fisica ad una base dati inviamo un comando in SQL nativo per quella particolare base dati per interagire con il modello logico che rappresenta la struttura fisica dei dati in un particolare database, ed eventualmente riceviamo uno stream di dati ai quali accediamo attraverso un approccio cursor-based in sola lettura. Per interagire con l’EDM, l’Entity Framework ci mette a disposizione un particolare Data Provider ADO.NET chiamato EntityClient. Quest’ultimo presenta l’identico pattern di utilizzo, ma invece di interagire con delle righe e delle colonne ci permette di interagire con delle entità. Accetta quindi un comando che, invece di essere in SQL nativo, ha una nuova sintassi orientata alle entità chiamata Entity SQL (o eSQL), indipendente dal dialetto SQL utilizzato dalla base dati sottostante e dalla struttura logica del database. Questo eSQL “capisce” invece quanto definito nell’EDM (meglio dire nei metadati generati a partire dall’EDM) in termini di relazioni, navigabilità tra le entità e quant’altro. Quando un comando eSQL viene passato all’EntityClient Provider questo lo traduce in un albero di comandi chiamato CCT (o Canonical Command Tree) che viene a sua volta girato all’ADO.NET Data Provider sottostante. Infatti, perchè quest’ultimo sia utilizzabile con EF ha come requisito fondamentale la capacità di ricevere un CCT e di tradurlo nel dialetto SQL che la base dati utilizzata è in grado di risolvere. In seguito all’esecuzione di questo comando l’ADO.NET Data Provider potrà restituire un DataReader all’EntityClient che, in accordo con quanto definito nei metadati generati a partire dall’EDM, prenderà i dati restituiti con un certo formato dalla base dati e li “manipolerà” restituendoli al chiamante con la “forma” delle entità richieste dalla query eSQL. A livello di mapping, i metadati contengono le informazioni legate all’area concettuale (CSpace, l’EDM vero e proprio), all’area di storage (SSpace, tutto ciò che è legato al modello logico dello spazio di storage, tabelle tipicamente ma potrebbe essere altro) e al mapping tra questi due “spazi” di rappresentazione delle informazioni. Questi metadati vengono generati a partire dai tre “asset” chiamati CSDL, MSL e SSDL, oggi conosciuti come schema XML, eventualmente embedded negli assembly della nostra applicazione ma domani chissà… :)

Fino a qui, nulla di tutto questo ha a che fare direttamente con le funzionalità di un O/RM, mentre ha molto a che fare con una sorta di “azionabilità” o utilizzabilità dell’EDM da parte di altre tecnologie che necessitano di un modello concettuale di astrazione rispetto a diverse rappresentazione logiche di dati di natura diversa.

Entity Framework e O/RM

Dove EF inizia a sovrapporsi a tecnologie di Object/Relational Mapping è con l’entrata in campo degli Object Services, componente che abbandona il pattern Connection/Command/Reader per abbracciare concetti quali ObjectContext, DataClasses e ObjectQuery<T>. Gli Object Services possono ancora ricevere comandi in termini di eSQL, come l’Entity Client, ma invece di ritornare un Reader il risultato di una query è una enumerazione di qualche tipo (IEnumerable<T>), la materializzazione di oggetti sulla base delle informazioni restituite dai layer inferiori e delle informazioni relative al modello a oggetti (OSpace) e al mapping (OCSpace) contenute nei metadati. I servizi offerti sono relativi, per esempio, alla materializzazione degli oggetti secondo quanto richiesto dai comandi eseguiti al tracking dello stato delle istanze degli oggetti materializzati e alla persistenza delle modifiche nella base dati sottostante.

Essendo ObjectQuery<T> una implementazione di IQueryable<T>, diventa naturale intuire che gli Object Services di EF sono naturalmente un provider LINQ e consentono quindi anche questa ulteriore modalità, oltre a eSQL di interagire con lo stack sottostante.

Sicuramente in un confronto 1:1 con un tool O/RM esistente come NHibernate (POCO, Lazy Loading, ecc.) o altri, quanto messo a disposizione da EF in questo campo ha dei limiti (come ammesso anche da Tim, PM del prodotto) che la v2 sembra in grado di ridurre rapidamente (qui e qui trovate già alcune implementazioni fatte da persone del team per testare gli scenari per la v2), ma l’obiettivo non è esattamente questo, quanto piuttosto una visione di più ampio respiro che spero queste mie riflessioni abbiano in qualche modo iniziato a spiegare.

More to come…