Ero troppo curioso di provare la nuova versione (beta) dei Tools per EF. Diciamo che la curiosità è stata parzialmente ripagata 
dato che con la prima versione non riuscii a fare granché essendo, almeno nella mia configurazione software, non molto stabile. Andiamo con ordine: dopo aver installato la nuova versione dei Tools, ho provato subito ad eseguire la funzione “Reverse Engineer Code First” (disponibile come voce di menu contestuale selezionando un progetto C#).
Per l’esperimento ho scelto un database con diverse tabelle, relazioni e “gerarchie”. Dopo aver cliccato sulla voce precedente, VS ha iniziato a “macinare” generando una sfilza di classi, suddividendole opportunatamente in classi di Mapping, Object Model e DbContext:
L’operazione è durata pochi secondi. Secondo il post del team di ADO.NET EF, VS avrebbe dovuto scaricare ed installare (se non già presente nel progetto) l’ultima versione di Entity Framework (nello specifico caso non è accaduto, ma con NuGet, anche questa operazione è durata poco ). Scorrendo l’elenco delle classi generate noto come il processo di reverse engineering abbia creato delle classi anche per le tutte le viste presenti sul database. Proviamo ad analizzare “graficamente” il modello ad oggetti creato, selezionando nel Solution Explorer la classe derivata dal DbContext e poi la voce “View Entity Data Model (Read Only)”:
Molte delle classi “isolate” sono proprio le classi\viste generate dal VS. Con le altre opzioni disponibili possiamo, creare il DDL SQL:
e visualizzare l’Entity Data Model XML:
Se siamo curiosi, possiamo creare un nuovo database a partire dalle classi generate da VS e poi eseguire uno Schema Compare per visionare le differenze tra l’originale ed il generato:
A colpo d’occhio mancano, rispetto all’originale, Stored Procedure e Viste, poi analizzando nel dettaglio le varie tabelle possiamo trovare alcune differenze come VARCHAR in NVARCHAR, valori di default mancanti, campi TEXT trasformati in NVARCHAR(MAX). Riassumendo, i Tools sembrano essere abbastanza stabili (rispetto alla versione precedente nessun crash ) , quello che è certo (almeno fino ad ora) che dovendo partire da un database esistente, sviluppare le classi POCO e DbContext con questa rapidità non ha prezzo, ma sicuramente è necessario un ulteriore lavoro di “fino” (magari in combinazione con EF Code First Migrations) se l’obiettivo è quello di avere un modello finale “fedele” all’originale, in caso contrario è un ottima base di partenza per un refactoring.